Re: [ippm] New Version Notification for draft-geib-ippm-connectivity-monitoring-03.txt

[[e-mail]]

Hi Ignacio,

Thanks for supporting adoption. 

The doc you refer to mentions " Principal component analysis" to figure out which overlaid measurements dominate an observed behavior (sets of origin to destination flow samples and observed link load). As the topology of the network to be monitored is assumed to be known as prerequisite of the suggested metric, the "principal component" to be detected is, e.g., a congested interface (a lost connectivity is a different one). As topology and measurement paths are set-up in pre-designed and controlled way, it is known at set up time, which changes in the measurements are caused by which event (with the expectation of a singular change to be detected only). 

Al asked me to provide text on the change point detection mechanism. Consecutive delay measurements on a single measurement path are supposed to be constant without congestion. So the difference between delays d1(t1)-d1(t0) == 0. It is non zero in case of congestion at time t1. That will be the core point (but that in itself isn't a change point detection). I'm thinking about cumulative sums with some noise tolerance here and will put that down in the next version.

Regards,

Rüdiger


-----Ursprüngliche Nachricht-----
Von: J Ignacio Alvarez-Hamelin <[e-mail]> 
Gesendet: Montag, 16. November 2020 16:14
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]; [e-mail]
Betreff: Re: [ippm] New Version Notification for draft-geib-ippm-connectivity-monitoring-03.txt

Dear Rüdiger,

I agree that the paper intends to do another thing. My point is, if you know the topology, you have to choose the minimum number of paths to make the measurements.  Part of the paper that I suggested and thought could be useful is to select the paths regarding the graph adjacency matrix (and no the measurements itself). There are multiple methods; I just signaling this one because it is one of the first work to do so, for my knowledge. I hope that could be useful for you. 

By the way, I support this draft draft-geib-ippm-connectivity-monitoring.


Best,

	J. Ignacio


_______________________________________________________________

Dr. Ing. José Ignacio Alvarez-Hamelin
CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
[phone] / 5285 0705
e-mail: [e-mail]
web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
_______________________________________________________________



> On 16 Nov 2020, at 05:46, <[e-mail]> <[e-mail]> wrote:
> 
> Dear Ignacio,
> 
> Thanks. I agree that one should minimize the number of measurements required to monitor a desired set of paths. That was one of my motivations when I designed the method specified by the draft.
> 
> There are however some differences between the document you've referenced below and my approach:
> - the authors of "Structural analysis of network traffic flows" had limited means of detecting the network topology. They further were able to set up SPF single origin to single destination measurements only. Finally, the exact SPF path taken in a network was often part of what was to be detected. 
> - My / the drafts starting point is: exact knowledge of the topology and the ability to concatenate and forward packets along sets of SPF paths by Segment Routing. By that, my design aim was to measure, what a ping can measure with no more packets than a ping and add location of congestion while not requiring router interaction apart from forwarding. That is a minimisation already (I didn't think I need to propose any new draft if it required more packets or measurement paths than a ping). Taking that point of view, who auf the WG is having a better idea to further minimize the number of paths while being able to extract "ping" data, add location of congestion and stay in forwarding is invited to publish. 
> 
> Regards,
> 
> Ruediger
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: J Ignacio Alvarez-Hamelin <[e-mail]>
> Gesendet: Montag, 16. November 2020 08:00
> An: Geib, Rüdiger <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Betreff: Re: [ippm] New Version Notification for 
> draft-geib-ippm-connectivity-monitoring-03.txt
> 
> Dear Ruediger,
> 
> It is an excellent proposition that I saw in the papers some time ago. Network tomography is somehow complicated because it would like, if I understand correctly, to measure different paths and characteristics with a minimum of paths. Could you consider to include some technique to compute these paths? I know that isn't very easy, but it could be a precious improvement. I know that is dependent on the topology, but there are some excellent techniques to reduce the fraction of paths to measure. I include a paper doing this through the reduction of the number of paths (there are others):
> 
> Lakhina A, Papagiannaki K, Crovella M, Diot C, Kolaczyk ED, Taft N. Structural analysis of network traffic flows. In Proceedings of the Joint International Conference on Measurement and Modeling of Computer Systems 2004 Jun 1 (pp. 61-72).
> 
> Perhaps you can cite this work as a possible method to compute that and include some methodology about the selection on the end-points, which leads to define the size of the problem and improve your proposition. Why is the size important? Because you would like to use the minimum number of testing paths to minimize the traffic and process them quickly. Besides, this technique could be used in many cases, not just in a particular topology. Eventually, I can help with this particular point. 
> 
> 
> 
> Best regards,
> 
> 	J. Ignacio
> 
> _______________________________________________________________
> 
> Dr. Ing. José Ignacio Alvarez-Hamelin
> CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av. 
> Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
> [phone] / 5285 0705
> e-mail: [e-mail]
> web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
> _______________________________________________________________
> 
> 
> 
>> On 3 Jul 2020, at 05:41, [e-mail] wrote:
>> 
>> Dear chairs,
>> 
>> draft-geib-ippm-connectivity-monitoring has been presented during the IPPM IETF 107. 
>> The new version addresses the request to add information on periodicity of the measurements. 
>> I've added text in section 3.8 "Reporting the metric". Minor changes 
>> in the introduction aim on better comprehensibility.
>> 
>> I don't participate at IETF 108 (online registration is charged this time, bad for participants in vacation). 
>> I'd nevertheless ask for adoption as a WG doc (but that may also be 
>> postponed until IETF 109, when I will try to participate and present 
>> the draft). Comments on the draft and your guidance regarding steps to adoption is welcome.
>> 
>> Regards,
>> 
>> Ruediger
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: [e-mail] <[e-mail]>
>> Gesendet: Freitag, 3. Juli 2020 10:16
>> An: Geib, Rüdiger <[e-mail]>
>> Betreff: New Version Notification for 
>> draft-geib-ippm-connectivity-monitoring-03.txt
>> 
>> 
>> A new version of I-D, draft-geib-ippm-connectivity-monitoring-03.txt
>> has been successfully submitted by Ruediger Geib and posted to the IETF repository.
>> 
>> Name:		draft-geib-ippm-connectivity-monitoring
>> Revision:	03
>> Title:		A Connectivity Monitoring Metric for IPPM
>> Document date:	2020-07-03
>> Group:		Individual Submission
>> Pages:		13
>> URL:            https://www.ietf.org/internet-drafts/draft-geib-ippm-connectivity-monitoring-03.txt
>> Status:         https://datatracker.ietf.org/doc/draft-geib-ippm-connectivity-monitoring/
>> Htmlized:       https://tools.ietf.org/html/draft-geib-ippm-connectivity-monitoring-03
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-geib-ippm-connectivity-monitoring
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-geib-ippm-connectivity-monitoring-03
>> 
>> Abstract:
>>  Within a Segment Routing domain, segment routed measurement packets  
>> can be sent along pre-determined paths.  This enables new kinds of  
>> measurements.  Connectivity monitoring allows to supervise the state  
>> and performance of a connection or a (sub)path from one or a few  
>> central monitoring systems.  This document specifies a suitable  
>> type-P connectivity monitoring metric.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>> 
>> _______________________________________________
>> ippm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ippm
>