Re: [ippm] [spring] Monitoring metric to detect and locate congestion

Ruediger.Geib@telekom.de Mon, 02 March 2020 16:02 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 781A73A0A1D; Mon, 2 Mar 2020 08:02:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 Ey4jDPMpbMoV; Mon, 2 Mar 2020 08:02:29 -0800 (PST)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412073A09C6; Mon, 2 Mar 2020 08:02:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1583164948; x=1614700948; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z1L3ZIT0pPjZs1hjW4lAG8wuVp1zjJCSLkvUExkdQrk=; b=pS0atn0B7aYmGNjElqU8df1kNrHhotxlF17/elL6NqTUtOJExg5UgKpe hmAxTCF6iXymKIc9/arKmliwP46iXDdX1hrxjSsLLiLEYqP/TLRyzJZ8M YTQvt09IXKEq5m1x0mndIGzvLbWlkt/l8wYYXE1DCZDrmWgWWWPKynXS9 xh3yqVhyExN8txV+1myMGeIlBDXmm2tEetY+HXm95XJXbdcuiX6qJ9CfT zgJbVN2ygZfSQTdKfNBuwOKo2XZ1QV5/7MMMCbFHWz/d+L7rGF6cCZjFV O5AgSEaZxlwHBWvPAf5ulSUZ273Cr8XhKib2tu6JNoGFcJGDvc/mSUcWq g==;
IronPort-SDR: RDdlI/3LayGzrtuINkBO06xGHL71e8E5ICVM4NicvUzAcngYRP2TOVAU/frmzdHXgT9gDxdxKQ MScXMToD4xig==
Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2020 17:02:26 +0100
IronPort-SDR: 5WKN5dukd+vEFG9N+pGSEpBnCiuwJBjMPhF12uaDxB4NFG1LKcWoDQBGPQrgldDJYbdYmT/fLu +GP9WWAfS0vXIJF+pIZC6j8YT4J1tVdW4=
X-IronPort-AV: E=Sophos; i="5.70,507,1574118000"; d="scan'208,217"; a="55198561"
X-MGA-submission: =?us-ascii?q?MDFc7pBYNbCvSsL+PZ6krGvV2qHCJhIbaZXZ40?= =?us-ascii?q?yhuXFsp3JELp9mFcl3U246vlr0pZSHni0YeY0g21yJaUJmW2c39GWc3v?= =?us-ascii?q?Cg1uTYkqqWi4yJqfrIEFZAGQ3EQEcA6gBVQa9O5UyriLCmqW0fQO6ZnT?= =?us-ascii?q?5J7t24EhgEuptrAdF9J6rl1g=3D=3D?=
Received: from he199744.emea1.cds.t-internal.com ([10.169.119.52]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 02 Mar 2020 17:02:25 +0100
Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199744.emea1.cds.t-internal.com (10.169.119.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Mar 2020 17:02:25 +0100
Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 2 Mar 2020 17:02:25 +0100
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.24) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Mar 2020 17:02:24 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DDMP9d0VBEE08dCzLRao3h+kNyKiLaspEripNSg+iSwhc4aweGOXqtvrISIbzG?= =?utf-8?q?5Wypv7y39FsP7g3E5vw1MQeOTAJUvqAjN6yowGZ+85scVVgTjb+rRUr8M27ilwtty?= =?utf-8?q?yKnXEkPYaHGaFi4J6SBaepL3R7M5nnSC8t4UtHEQU0SHRL2TUdyC2Km1msWYwhJmy?= =?utf-8?q?uQlpAFcWs+q58T4iZtYEtAf9CEFf5SOMMN4DINpFJRfP/+ie2PORXu+UelcxLIgo6?= =?utf-8?q?MUgiSjfH3PQVl9XsM0QBMBwRECx3i6WVKIMjuntftkWFJHJuD5d+sYCfxWxDXyzfw?= =?utf-8?q?unLWEanNcCXX0mmILUp1A=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DZ1L3ZIT0pPjZs1hjW4lAG8wuVp1zjJCSLkvUExkdQrk=3D=3B_b=3DLSfZEs?= =?utf-8?q?nilnQBiOIdMCB2rOAnrnwuC4d3qmOrJCRORh3srFzU57Ad9Ox5mhuvbnC+nU13tMJ?= =?utf-8?q?68EPUjY5JF0IHjc/oTcD4+7CLt8poeg+MWrpksfdSAmiXms5SQaH3LXb10yfmELyF?= =?utf-8?q?i+Y2Uv4UmzdusJsoYn54QboAl7R/Breng1IhtlcX0NetRgyFs1OuVcTVjxArmwiXl?= =?utf-8?q?wayZXzXN2vORCj9SnrqtQy6+dS2J0MBkrYIqoQ2N0GKdXAxgCj9erbRPjD4TdwOuP?= =?utf-8?q?mABYCkC33WoLipscOC6qbp2YHy1s7cn1ZlIy6pG5YTlvdoJHYs0hLyWkimql/wN4O?= =?utf-8?q?3Dn011nA/Ug=3D=3D?=
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from FRXPR01MB0392.DEUPRD01.PROD.OUTLOOK.DE (10.158.152.135) by FRXPR01MB0325.DEUPRD01.PROD.OUTLOOK.DE (10.158.156.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.19; Mon, 2 Mar 2020 16:02:24 +0000
Received: from FRXPR01MB0392.DEUPRD01.PROD.OUTLOOK.DE ([fe80::911e:8edf:2d06:6214]) by FRXPR01MB0392.DEUPRD01.PROD.OUTLOOK.DE ([fe80::911e:8edf:2d06:6214%4]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 16:02:24 +0000
From: <Ruediger.Geib@telekom.de>
To: <zhoutianran@huawei.com>
CC: <spring@ietf.org>, <ippm-chairs@ietf.org>, <ippm@ietf.org>
Thread-Topic: [spring] Monitoring metric to detect and locate congestion
Thread-Index: =?utf-8?q?AdXsd9MS3uEh95p5QyK2WBDxA74xnQBK4HLQAADxJwAAABLocAAA?= =?utf-8?q?6fiAAADLqyAACYSrAAAAMrQwAACe9YAAtOTEsA=3D=3D?=
Date: Mon, 2 Mar 2020 16:02:23 +0000
Message-ID: =?utf-8?q?=3CFRXPR01MB03928884BE840262BF8599AF9CE70=40FRXPR01MB0?= =?utf-8?q?392=2EDEUPRD01=2EPROD=2EOUTLOOK=2EDE=3E?=
References: =?utf-8?q?=3CFRXPR01MB03926E7F0A28B837D69C3C819CEA0=40FRXPR01MB0?= =?utf-8?q?392=2EDEUPRD01=2EPROD=2EOUTLOOK=2EDE=3E_=3CBYAPR13MB2485E450C9A23?= =?utf-8?q?0E4A54104769AEB0=40BYAPR13MB2485=2Enamprd13=2Eprod=2Eoutlook=2Eco?= =?utf-8?q?m=3E?= =?utf-8?q?=3CCAOj+MMFskpmOmc+xqf3K=5FnU7ePaXbTCF97nvKabdCa0xOosr=5Fg=40mail?= =?utf-8?q?=2Egmail=2Ecom=3E_=3CBYAPR13MB2485F3CFC7A36DE45352F7189AEB0=40BYA?= =?utf-8?q?PR13MB2485=2Enamprd13=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CCAOj+MMHPU-EvGXSSe6959YLHF2TuaBub66DNcvvMKmbfz-XLpA=40mail=2Eg?= =?utf-8?q?mail=2Ecom=3E_=3CBYAPR13MB24852B404FE4B3FE114397F29AEB0=40BYAPR13?= =?utf-8?q?MB2485=2Enamprd13=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CBBA82579FD347748BEADC4C445EA0F21BF254EF1=40NKGEML515-MBX=2Echi?= =?utf-8?q?na=2Ehuawei=2Ecom=3E_=3CBYAPR13MB2485AC1197EFEAFB8D85165D9AE80=40?= =?utf-8?q?BYAPR13MB2485=2Enamprd13=2Eprod=2Eoutlook=2Ecom=3E?= <BBA82579FD347748BEADC4C445EA0F21BF254F30@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <BBA82579FD347748BEADC4C445EA0F21BF254F30@NKGEML515-MBX.china.huawei.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: [164.19.4.196]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3971060c-aac2-48bc-d9ac-08d7bec318d2
x-ms-traffictypediagnostic: FRXPR01MB0325:
x-microsoft-antispam-prvs: =?utf-8?q?=3CFRXPR01MB0325408BC034356E67C1F1F29CE?= =?utf-8?q?70=40FRXPR01MB0325=2EDEUPRD01=2EPROD=2EOUTLOOK=2EDE=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 033054F29A
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=283986?= =?utf-8?b?MDQwMDAwMikoMTM2MDAzKSgzNjYwMDQpKDM0NjAwMikoMzk2MDAzKSgzNzYwMDIp?= =?utf-8?b?KDE4OTAwMykoMTk5MDA0KSg3Njk2MDA1KSg2Njk0NjAwNykoNzYxMTYwMDYpKDE4?= =?utf-8?q?6003=29=286916009=29=288936002=29=28478600001=29=285660300002=29?= =?utf-8?q?=2833656002=29=289326002=29=2886362001=29=2881156014=29=285490600?= =?utf-8?b?MykoODY3NjAwMikoNTUwMTYwMDIpKDk2ODYwMDMpKDI2MDA1KSg5NjYwMDUpKDgx?= =?utf-8?q?166006=29=28316002=29=2819627235002=29=282906002=29=2853546011=29?= =?utf-8?q?=2871200400001=29=284326008=29=2866446008=29=2864756008=29=286655?= =?utf-8?q?6008=29=2885202003=29=2866476007=29=2885182001=29=28777600001=29?= =?utf-8?q?=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0325; H:FRXPR01MB0392.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: =?utf-8?q?PiLW0/YA2lxiqQyOOoh+OrgSa/iJejG?= =?utf-8?q?fum12AUxLQs1Tjg+ak0m7/OmC+Jt8TXuwLTBAl/j9tW4ieg7ysgrnl9l5ecClE+v1?= =?utf-8?q?7+j53L8p4NGkOi8VMUXqKCOq0iEFobQD/yn0wAxVbENk3O2OLQ2djfrGLlxleKenV?= =?utf-8?q?PeYg/I0+UpaYVO4i6iHaNdqW+k8F9dg/X9G8WKmpx6pU3+v3xUVXMv/lN7oYFlW6X?= =?utf-8?q?lTA2wB0IwPMpkw0Pnns5TYZx62nO6tjAnli6Qv8aYVIcH1xp5x0W8Lz6HuAtk1ybe?= =?utf-8?q?LSUz6TxxXOs8ZBMoYHNX6RoMUDc9vEWfQG7VkJf0dO62uITACDSQ2OPUu6yHPhU5A?= =?utf-8?q?07C66Yh/T1IdaeeBPds+JgTni8JIS3d7/sucOa+iqsEhOb3LOUCnjAJvumKkz5vBv?= =?utf-8?q?qJChyPfRsdfYHlPAlfsnqL/h0YuNtpPuX7cL3GmwNhulKo8A7zi5C52nD6M96hfBX?= =?utf-8?q?DQnBpP9sIof6IkcvrFD9YKoCbrNOw4aqrmFEDREF0zaGCYMsosHzldqCpGK4Uz/sL?= =?utf-8?q?tf3Q=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?DEV8IKbOSah/4WuKljhjRXqw7t7wud?= =?utf-8?q?OXRRaUgYemjfheU87gSFfg1SiWh8SSwrJJ4+uLSRn/b5R64EcQkcAVXQOpei6Wu3E?= =?utf-8?q?NEXY5hdBo4cl5wITV3P47AoNDKzFkfL9sou/QKxYyWPqo9D1cnGGcYQ=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_FRXPR01MB03928884BE840262BF8599AF9CE70FRXPR01MB0392DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3971060c-aac2-48bc-d9ac-08d7bec318d2
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 16:02:23.9616 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: =?utf-8?q?kbP9yEfC6Bi42MtA1Yj65?= =?utf-8?q?h/Yloeu1ZUXLu3TSoDfqDpPs3kz0FApwK3bl4jAlrCQH5vEdZqJs6f5CBcLaDwkpH?= =?utf-8?q?NnPe7r8jGYmC00WTZsQpk=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB0325
X-TM-SNTS-SMTP: 9F1A39994EACEC777ECE1E8EC2D305437F7E02BDD6DAC322BBF63A35002A7B0B2000:8
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/MpG0lS0T_hA0CdNMgIttfJqKFbA>
Subject: Re: [ippm] [spring] Monitoring metric to detect and locate congestion
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, 02 Mar 2020 16:02:39 -0000

Hi Tianran,

using node based information like added by IOAM is another valid option. The method I propose is to stay at forwarding layer and work without node support. That way forwarding issues are detected, even if the control plane isn’t aware of it. Also that happens.

Active measurements and IOAM can be combined, and that might be useful.

Regards,

Ruediger


Von: spring <spring-bounces@ietf.org> Im Auftrag von Tianran Zhou
Gesendet: Freitag, 28. Februar 2020 02:37
An: Haoyu Song <haoyu.song@futurewei.com>om>; Robert Raszuk <robert@raszuk.net>
Cc: spring@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org
Betreff: Re: [spring] Monitoring metric to detect and locate congestion

I take the second point. But it also gives short coming, the probe cannot take many data in one packet.
The first point I do not understand.
You said “combination ingress+egress queuing information on each transit node”. I suppose you mean all the queues information in this node. This in my opinion can only be collected in control plane.

Best,
Tianran

From: Haoyu Song [mailto:haoyu.song@futurewei.com]
Sent: Friday, February 28, 2020 9:23 AM
To: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>
Subject: RE: [spring] Monitoring metric to detect and locate congestion

Two key differences. (1) you want to do this purely in data plane fast path. (2) you don’t want to keep a streaming session from each node for scalability reason
The path probing approach can meet both requirements.

Haoyu

From: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
Sent: Thursday, February 27, 2020 5:14 PM
To: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>
Subject: RE: [spring] Monitoring metric to detect and locate congestion

This is a good point. In this way, the probe is generically used to collect node data.
At each node, the probe will be send to the slow path to get the node data. Data could be carried in the payload which has more space.
Then, what’s the difference to existing way that Robert mentioned? Use streaming telemetry to export from each node.
As far as I know the state of art, many device support streaming telemetry can export in a period of 1-10 seconds. For customized data, the period could even be reduced to 10-100ms.

Best,
Tianran


From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Haoyu Song
Sent: Friday, February 28, 2020 4:44 AM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>
Subject: Re: [ippm] [spring] Monitoring metric to detect and locate congestion

Can the combination ingress+egress queuing information on each transit node be collected by simply visit the node? If so, one or more probing paths that can cover all the nodes are sufficient.

Best,
Haoyu

From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: Thursday, February 27, 2020 12:18 PM
To: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
Cc: Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>; ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>
Subject: Re: [spring] Monitoring metric to detect and locate congestion

The point is not to assure all egress ports are inspected.

The point of any really useful end to end path probing is to find out if combination of ingress+egress queuing on each transit node my packet may traverse are not congested.

Looking at Eulerian path algorithm I do not see such guarantees.

Best,
R.

PS. Path probing is A1 to B1. It is not A1 to B1, B2 .. Bn. where An are the ingress ports to the network and Bn are the egress ports.

On Thu, Feb 27, 2020 at 9:14 PM Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>> wrote:
Hi Robert,

The Eulerian path algorithm guarantees to visit all the edges of a graph. In the SR context, we can consider the sub-path between two segments an edge.

Haoyu

From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: Thursday, February 27, 2020 11:50 AM
To: Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>>
Cc: Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>; ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>
Subject: Re: [spring] Monitoring metric to detect and locate congestion

Hi Haoyu,

> which applies Eulerian Path algorithm to find the minimum set of paths with network-wide coverage.

In practice networks use ECMP. ECMP decision may happen at each hop. Your end to end flows get spread over all ECMP paths. So limiting number of probed paths is inaccurate to the fundamental objective of the exercise.

That is infact main challenge with any end to end path probing today ... if you do not cover all possible paths your packets may take between ingress and egress you just do not get full picture of the network.

Thx a lot,
R.


On Thu, Feb 27, 2020 at 8:44 PM Haoyu Song <haoyu.song@futurewei.com<mailto:haoyu.song@futurewei.com>> wrote:
Hi Ruediger,

I like the general idea that using pre-determined paths in SR to collect performance metrics. I think this approach provides some unique benefits compared with the other approaches. It is also coincident with some of related research work I’m doing.
Here are some thoughts I have.

  1.  I think IOAM could be used as the standard approach for such probing packets. It can collect the performance metrics mentioned in the draft and does more.
  2.  An interesting problem raised by the draft but not fully addressed is the method to plan the optimal paths. There is a work called INT-PATH (https://ieeexplore.ieee.org/document/8737529<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F8737529&data=02%7C01%7Chaoyu.song%40futurewei.com%7C03811f6f80554f7dad6408d7bbeb74f0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637184492271070940&sdata=CMFuDR26gKPUjOYu3vcVlWNoTP%2FA%2FGiCIEnxERVBZmk%3D&reserved=0>) which applies Eulerian Path algorithm to find the minimum set of paths with network-wide coverage. However, the problem here seems different: you need path coverage redundancy. My question is: do we really need the redundancy to achieve the measurement goal? If so, what’s the best planning algorithm should be? In a real and large scale network, we have constraint on where the probing device(s) can be placed, and we usually want to monitoring the entire network, so an efficient algorithm is necessary.

Best regards,
Haoyu

From: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> On Behalf Of Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>
Sent: Tuesday, February 25, 2020 11:55 PM
To: ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>
Cc: spring@ietf.org<mailto:spring@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>
Subject: [ippm] Monitoring metric to detect and locate congestion

Dear IPPM (and SPRING) participants,

I’m solliciting interest in a new network monitoring metric which allows to detect and locate congested interfaces. Important properties are

  *   Same scalability as ICMP ping in the sense one measurement relation required per monitored connection
  *   Adds detection and location of congested interfaces as compared to ICMP ping (otherwise measured metrics are compatible with ICMP ping)
  *   Requires Segment Routing (which means, measurement on forwarding layer, no other interaction with passed routers – in opposite to ICMP ping)
  *   Active measurement (may be deployed using a single sender&receiver or separate sender and receiver, Segment Routing allows for both options)

I’d be happy to present the draft in Vancouver... If there’s community interest. Please read and comment.

You’ll find slides at

https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-14-draft-geib-ippm-connectivity-monitoring-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F105%2Fmaterials%2Fslides-105-ippm-14-draft-geib-ippm-connectivity-monitoring-00&data=02%7C01%7Chaoyu.song%40futurewei.com%7C03811f6f80554f7dad6408d7bbeb74f0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637184492271070940&sdata=tL%2FtbMJ0Ei2e%2FUFZyBB2GFPEhj8qzCuWXo5upM9GNsE%3D&reserved=0>

Draft url:

https://datatracker.ietf.org/doc/draft-geib-ippm-connectivity-monitoring/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-geib-ippm-connectivity-monitoring%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7C03811f6f80554f7dad6408d7bbeb74f0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637184492271080924&sdata=qteR3ORsHz6mnbguKfMMQwcls9kaSi8NhAh9hFaH7b8%3D&reserved=0>

Regards,

Ruediger
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=02%7C01%7Chaoyu.song%40futurewei.com%7C03811f6f80554f7dad6408d7bbeb74f0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637184492271080924&sdata=cUScWh29Li%2BFBJHIYBm6fcylGx6zrv%2F4RtEM6b5YMvs%3D&reserved=0>