Re: [Detnet] Available ISP topologies in academic work

Antoine FRESSANCOURT <antoine.fressancourt@huawei.com> Wed, 27 March 2024 16:38 UTC

Return-Path: <antoine.fressancourt@huawei.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F63C157938 for <detnet@ietfa.amsl.com>; Wed, 27 Mar 2024 09:38:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level:
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_DOTEDU=1] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOw2RccrEtLD for <detnet@ietfa.amsl.com>; Wed, 27 Mar 2024 09:38:49 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B08C14F68F for <detnet@ietf.org>; Wed, 27 Mar 2024 09:38:48 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4V4XQl0QpCz6K5ly; Thu, 28 Mar 2024 00:37:51 +0800 (CST)
Received: from lhrpeml500001.china.huawei.com (unknown [7.191.163.213]) by mail.maildlp.com (Postfix) with ESMTPS id 41EEE140B18; Thu, 28 Mar 2024 00:38:45 +0800 (CST)
Received: from lhrpeml500003.china.huawei.com (7.191.162.67) by lhrpeml500001.china.huawei.com (7.191.163.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Wed, 27 Mar 2024 16:38:44 +0000
Received: from lhrpeml500003.china.huawei.com ([7.191.162.67]) by lhrpeml500003.china.huawei.com ([7.191.162.67]) with mapi id 15.01.2507.035; Wed, 27 Mar 2024 16:38:44 +0000
From: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
To: "peng.shaofu@zte.com.cn" <peng.shaofu@zte.com.cn>
CC: "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: [Detnet] Available ISP topologies in academic work
Thread-Index: Adp7oyC+EAAQ7zCeS1+2KYCkJXPKbQEiYBSAAA3+HfA=
Date: Wed, 27 Mar 2024 16:38:44 +0000
Message-ID: <257c219f3e734c499c6fd4a1310e474b@huawei.com>
References: 56baecbe18954627806ed624c4ef5701@huawei.com <202403271753334319USZpcuMdtMx2rLKpXdkh@zte.com.cn>
In-Reply-To: <202403271753334319USZpcuMdtMx2rLKpXdkh@zte.com.cn>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.206.215.65]
Content-Type: multipart/related; boundary="_004_257c219f3e734c499c6fd4a1310e474bhuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/XKxcfSrALGCVXSP35pYTGpVJjZQ>
Subject: Re: [Detnet] Available ISP topologies in academic work
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2024 16:38:53 -0000

Hello,

My idea when I shared those topologies was to answer the question raised during the WG meeting to find a topology and to address operators concerns. In my view, DEFO topologies could be good candidates because they are close to operator’s WAN topologies (or at least, they are the closest I could think of). I hope that my message was not taken as a wish to impose something or to mandate the use of such topologies.

Best regards,

Antoine

From: peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn>
Sent: mercredi 27 mars 2024 10:54
To: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
Cc: detnet@ietf.org
Subject: Re: [Detnet] Available ISP topologies in academic work




Hi Antoine,



Thanks for your sharing a potential topology.



I have a little different understanding about the ideal reference topology, that is I think it may not be any topology in the real network.



Since for any particular topology in reality, someone can easily add new nodes (and their links) to the topology and let new flows that are waiting for admission check pass through these new nodes/links, by carefully planned TE paths, to avoid congestion with old flows that are already running in the network.



As we always consider the worst-case when analyzing latency performance and service scale, the ideal topology is actually to observe each link separately.

That is, for each link, we assume that there are full competitive flows passing through it.

So the ideal reference topology may be like the following:

[cid:image001.png@01DA806D.9C504DB0]

Many papers use topologies similar to the above for verification. I also see the similar topology provided by Toerless during the discussion in the maillist.

For example, https://www.ieee802.org/1/files/public/docs2010/ba-boiger-bridge-latency-calculations.pdf construct full competed frames on each hop to illustrate the burstiness cascade of TSN CBS.



Regards,

PSF




Original
From: AntoineFRESSANCOURT <antoine.fressancourt=40huawei.com@dmarc.ietf.org<mailto:antoine.fressancourt=40huawei.com@dmarc.ietf.org>>
To: detnet@ietf.org<mailto:detnet@ietf.org> <detnet@ietf.org<mailto:detnet@ietf.org>>;
Date: 2024年03月21日 23:28
Subject: [Detnet] Available ISP topologies in academic work
_______________________________________________
detnet mailing list
detnet@ietf.org<mailto:detnet@ietf.org>
https://www.ietf.org/mailman/listinfo/detnet
Hello,

Bouncing on the call for topologies to evaluate large scale DetNet proposals, I reminded some topologies I have been using during my PhD time, a few years ago. Unfortunately, some Internet tomography projects have stopped since then, and given the growing criticality of the Internet infrastructure, it seems that publicly available ISP-level topologies are difficult to get.

The reference project people go to when looking for ISP-level topologies is Rocketfuel (https://research.cs.washington.edu/networking/rocketfuel/). It is old but topologies extracted from this dataset are still used for routing mechanism evaluation.

Some specific ISP topologies have been refined and complemented with demands from flows in DEFO (https://sites.uclouvain.be/defo/). DEFO uses both real topologies from Rocketfuel and synthetic topologies generated with iGen (https://informatique.umons.ac.be/networks/igen/). The missing aspect in DEFO’s augmented topologies is the lack of latency bounds or Jitter bounds for flows, inter-arrival times etc. . Maybe we can augment those topologies to fit with what we need as a group to evaluate large scale detnet options ?

Best regards,

Antoine Fressancourt