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

J Ignacio Alvarez-Hamelin <ihameli@cnet.fi.uba.ar> Mon, 16 November 2020 15:14 UTC

Return-Path: <ihameli@cnet.fi.uba.ar>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477F13A1148; Mon, 16 Nov 2020 07:14:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4Lt7eZnt_Pg; Mon, 16 Nov 2020 07:14:28 -0800 (PST)
Received: from cnet.fi.uba.ar (cnet.fi.uba.ar [157.92.58.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9AC3A115A; Mon, 16 Nov 2020 07:14:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by cnet.fi.uba.ar (Postfix) with ESMTP id BFDC5140077; Mon, 16 Nov 2020 12:14:22 -0300 (ART)
X-Virus-Scanned: Debian amavisd-new at cnet.fi.uba.ar
Received: from cnet.fi.uba.ar ([127.0.0.1]) by localhost (cnet.fi.uba.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-eddItEAqL6; Mon, 16 Nov 2020 12:14:16 -0300 (ART)
Received: from [192.168.0.13] (unknown [181.46.139.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by cnet.fi.uba.ar (Postfix) with ESMTPSA id 19938140068; Mon, 16 Nov 2020 12:14:16 -0300 (ART)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: J Ignacio Alvarez-Hamelin <ihameli@cnet.fi.uba.ar>
In-Reply-To: <FRAPR01MB0738D0DF496A16ABBA11851A9CE30@FRAPR01MB0738.DEUPRD01.PROD.OUTLOOK.DE>
Date: Mon, 16 Nov 2020 12:14:01 -0300
Cc: ippm-chairs@ietf.org, ippm@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <626A4A7E-0941-46F8-947E-4CC24DFC86CE@cnet.fi.uba.ar>
References: <159376413634.18432.970239984476460419@ietfa.amsl.com> <LEXPR01MB1040A37A44C31C3D51CE25309C6A0@LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE> <30B64F4F-6947-4ACB-8717-BF32143241EE@cnet.fi.uba.ar> <FRAPR01MB0738D0DF496A16ABBA11851A9CE30@FRAPR01MB0738.DEUPRD01.PROD.OUTLOOK.DE>
To: Ruediger.Geib@telekom.de
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/VCOzQrNxKmgy1cqmtKhpKK7XKy0>
Subject: Re: [ippm] New Version Notification for draft-geib-ippm-connectivity-monitoring-03.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 15:14:30 -0000

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
+54 (11) 5285 0716 / 5285 0705
e-mail: ihameli@cnet.fi.uba.ar
web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
_______________________________________________________________



> On 16 Nov 2020, at 05:46, <Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de> 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 <ihameli@cnet.fi.uba.ar> 
> Gesendet: Montag, 16. November 2020 08:00
> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
> Cc: ippm-chairs@ietf.org; ippm@ietf.org
> 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
> +54 (11) 5285 0716 / 5285 0705
> e-mail: ihameli@cnet.fi.uba.ar
> web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
> _______________________________________________________________
> 
> 
> 
>> On 3 Jul 2020, at 05:41, Ruediger.Geib@telekom.de 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: internet-drafts@ietf.org <internet-drafts@ietf.org>
>> Gesendet: Freitag, 3. Juli 2020 10:16
>> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
>> 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
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>