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

[[e-mail]]

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