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

[[e-mail]]

Hi Ignacio,

by congestion I consider indeed buffer queues to fill (and random drops may occur). This should result in delay increase which is significant as compared to other efforts. The latter are still present, but on a smaller timescale. As an example, I'd guess a delay or an RTT may vary by +/- 200 us in backbone network (interfaces of bandwidth 1/10/100 GE). Let's call that "noise". Then the change point detection should recognize delay increases by say 1 ms or more. Just an example, numbers may be settable to reflect conditions of different environments. If "noise" and congestion result in delay changes of similar duration, location of changes may be more difficult or not work at all. 

Let me come up with a changepoint detection algorithm and then see where to go next. 

There are other options, like capturing (simple) statistics describing the noise and a (tolerant) check, whether any new measurement is likely drawn from that distribution. I think, that should depend on operator preferences and certainly is open for research. 

Regards,

Rüdiger



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

Hi Rüdiger, 

Just another comment on the congestion: You cannot rely on the RTT change because its statistical distribution is complex. In some cases, RTT on a link can be assumed Gaussian, but the general case is the alpha-stable, a generalization of the Gaussian one. The underlying distribution is important because you will face heavy tail distributions where average and standard deviation have no meaning. Notice that measurements are correlated with the time-window to compute them. Another point that needs to take care of is that it is not clear the definition of congestion, as always happens. For some people means one thing, like "the link utilization is less than 95% of its capacity,"; which leads to having some systematic errors because it changes according to the selected time-window. What do you intent to characterize as "congestion"? In my opinion, one solution is to analyze if delays are highly increased; for instance, when some link is overload, its buffer is plenty (introducing some extra delay), and a lot of packets are discarded.

If you consider it useful, I can collaborate on this point. 

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 19 Nov 2020, at 10:14, <[e-mail]> <[e-mail]> wrote:
> 
> 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
>> 
>