[Din] Re: next steps for DINRG
Dirk Trossen <dirk.trossen@huawei.com> Tue, 22 October 2024 17:08 UTC
Return-Path: <dirk.trossen@huawei.com>
X-Original-To: din@ietfa.amsl.com
Delivered-To: din@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040D5C151522 for <din@ietfa.amsl.com>; Tue, 22 Oct 2024 10:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.636
X-Spam-Level:
X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 VP4PdEj4mXyo for <din@ietfa.amsl.com>; Tue, 22 Oct 2024 10:08: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 DA863C151095 for <din@irtf.org>; Tue, 22 Oct 2024 10:08:48 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XXz6Z5llTz6LD4k; Wed, 23 Oct 2024 01:04:06 +0800 (CST)
Received: from frapeml100001.china.huawei.com (unknown [7.182.85.63]) by mail.maildlp.com (Postfix) with ESMTPS id ED3D6140B2A; Wed, 23 Oct 2024 01:08:45 +0800 (CST)
Received: from frapeml500001.china.huawei.com (7.182.85.94) by frapeml100001.china.huawei.com (7.182.85.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 22 Oct 2024 19:08:45 +0200
Received: from frapeml500001.china.huawei.com ([7.182.85.94]) by frapeml500001.china.huawei.com ([7.182.85.94]) with mapi id 15.01.2507.039; Tue, 22 Oct 2024 19:08:45 +0200
From: Dirk Trossen <dirk.trossen@huawei.com>
To: Thomas Hardjono <hardjono@mit.edu>, "jon.crowcroft" <jon.crowcroft@cl.cam.ac.uk>
Thread-Topic: [Din] Re: next steps for DINRG
Thread-Index: AQHbIXyQcrl2gWgUakCXinvpY3YQVrKMw+OAgAV2WQCAAFhCgIAAdKQx
Date: Tue, 22 Oct 2024 17:08:45 +0000
Message-ID: D28DF02B-4818-4F41-9F5A-EC950F5BAA00
References: <18BAB346-D64A-40A3-A29B-9146562E5674@dkutscher.net> <6d66bdb8-b546-40b1-b723-ee8ac80b8adb@app.fastmail.com> <BYAPR01MB4391391642D149D59316D9F0CB402@BYAPR01MB4391.prod.exchangelabs.com> <CAEeTej+iRbi+cCuvKFRDaWU=XgpHR4xOMXZ9FpOo040gEwOQVw@mail.gmail.com>,<BYAPR01MB43914DB25C4DA4DB8441EF96CB4C2@BYAPR01MB4391.prod.exchangelabs.com>
In-Reply-To: <BYAPR01MB43914DB25C4DA4DB8441EF96CB4C2@BYAPR01MB4391.prod.exchangelabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_D28DF02B48184F419F5AEC950F5BAA00_"
MIME-Version: 1.0
Message-ID-Hash: DGU4UXXJQCDONMD5LHY74AHV3MNFVC6K
X-Message-ID-Hash: DGU4UXXJQCDONMD5LHY74AHV3MNFVC6K
X-MailFrom: dirk.trossen@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-din.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Chad Kohalyk <chad@kohalyk.com>, din <din@irtf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Din] Re: next steps for DINRG
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/bMj989KNxPLVl6t55hEvD8AnpQM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Owner: <mailto:din-owner@irtf.org>
List-Post: <mailto:din@irtf.org>
List-Subscribe: <mailto:din-join@irtf.org>
List-Unsubscribe: <mailto:din-leave@irtf.org>
David Guzman in a co-supervised PhD with Joerg Ott has looked into those centralisation realities for ETH deployments. Not quite a single country but quite a limited set of cloud ISPs. Got a paper coming up in the Context DIN workshop with some of those insights. Interesting discussions for the RG indeed. Best Dirk From:Thomas Hardjono <hardjono@mit.edu<mailto:hardjono@mit.edu>> To:jon.crowcroft <jon.crowcroft@cl.cam.ac.uk<mailto:jon.crowcroft@cl.cam.ac.uk>> Cc:Chad Kohalyk <chad@kohalyk.com<mailto:chad@kohalyk.com>>;din <din@irtf.org<mailto:din@irtf.org>> Date:2024-10-22 15:11:47 Subject:[Din] Re: next steps for DINRG +1 agree, thanks Jon. I think these kinds of ideas should be the meat of the discussions in DIN RG. --thomas From: Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk> Date: Tuesday, October 22, 2024 at 2:55 AM To: Thomas Hardjono <hardjono@mit.edu> Cc: Chad Kohalyk <chad@kohalyk.com>, din@irtf.org <din@irtf.org> Subject: Re: [Din] Re: next steps for DINRG what if 90% of those blockchain/cryptocurrency nodes are running in the same country on a network powerd by a single electricity provider? with a single state controlled border to the rest of the world, for IP and people? or indeed we could have a decentralised phone-based currency that requires SIMs from a specific provider and government regstraton of users of those SIMs/phones with national id cards/passports .... note the other way around, many cloud service providers are administratively/economically/politically (e.g. subject to laws from one dominant jurisdicrtion) centralised, but use decentralised or at least distributed or federated techniques to provide resilience - hence replicated state machines/consensus algorithms, conflict-free replicated data types all allow systems to scale across multiple data centers so that we get fault tolerance and continuous operation, but they are not organisationally decentralised in any way. On Fri, Oct 18, 2024 at 8:33 PM Thomas Hardjono <hardjono@mit.edu<mailto:hardjono@mit.edu>> wrote: Just some quick thoughts on the “What’s next” question. One of the things DINRG could focus on is the standards (architectures, protocols, etc.) and tools to measure the degree of decentralization of systems and networks (notably those DLT-based offerings that claim to be “decentralized”). Let’s say a DLT network (e.g. blockchain) has 100 nodes and the network claims to be operating in decentralized manner. What if it turns out that 90% of those nodes are actually VMs running in the cloud, and what if it turns out that 90% of those cloud-based VMs are running on the same Cloud Provider? (worse, what if they’re running on the same Zones, like US-West and US-East). Would you accept their claim of decentralization seriously? Some possible future work for DINRG: -- Could DIN look at protocols that report on which nodes are running on bare-metal, versus physically separated VMs, versus VMs clustered in a given zone. -- Could Device-ID and device-stack identifiers be useful (building on protocols defined in the RATS WG and TEEP WG). -- Could DIN leverage the work already being done in the IEF WGs (e.g. RATS, SCITT, etc), and also from other industry bodies (e.g. TCG DICE; OpenCompute; Confidential Computing Consortium; etc). -- Could DIN be the funnel/filter into which near-mature proposal can be fed into working groups in the IETF. An example of this was the Group Security RG (GSEC) that funneled some ready items into the MSEC WG. https://www.irtf.org/concluded/gsec.html https://datatracker.ietf.org/wg/msec/about/ PS. Yes I’m aware of economic papers/analysis stating that efficiency and cost-savings favors centralization. In contrast, I’m referring to future so-called Web3 systems that bake-in decentralization patterns to avoid these concentrations of power. Best --thomas From: Chad Kohalyk <chad@kohalyk.com<mailto:chad@kohalyk.com>> Date: Friday, October 18, 2024 at 12:41 PM To: din@irtf.org<mailto:din@irtf.org> <din@irtf.org<mailto:din@irtf.org>> Subject: [Din] Re: next steps for DINRG Thanks Dirk. One possibility is to discuss “What now?” I think that was one of the conclusions of the IETF120 discussion: who should DINRG collaborate with in order to effect change? In other words, what is DINRG’s theory of change? Where does the research go once it is complete? Is DINRG’s role purely observatory? On who’s behalf? (merely the IRTF?) Possibly these were answered when DINRG was stood up, but based on the conversation in Vancouver it didn’t seem like the community understood what’s next. So I submit this as a topic suggestion. Thank you, Chad Kohalyk On Fri, Oct 18, 2024, at 1:41 AM, Dirk Kutscher wrote: Dear all, in Dublin, we are planning to continue our discussion on next steps for DINRG. To that end, we are soliciting suggestions, interests indications, and questions here. If you have a suggestion, please feel free to share it here or by personal e-mail. We will collect everything and then prepare a summary before the meeting. As a bit of background: As chartered, DINRG has different objectives: * Investigation of the root causes of Internet centralization, and articulation of the impacts of the market economy, architecture and protocol designs, as well as government regulations; * Measurement of the Internet centralization and the consequential societal impacts; * Characterization and assessment of observed Internet centralization; * Development of a common terminology and understanding of (de-)centralization; * Interaction with the broader research community to explore new research topics and technical solutions for decentralized system and application development; * Documentation of the outcome from the above efforts via different means (e.g., research papers and RFCs) as inputs to the broader conversation around centralization; and * Facilitation of discussions between researchers, organizations and individuals involved in Internet standards and regulations. Let us know, which of these objectives should be emphasized in your view, and whether you have specific interests within these topics that should be discussed more. Best regards, Dirk and Lixia _______________________________________________ Din mailing list -- din@irtf.org<mailto:din@irtf.org> To unsubscribe send an email to din-leave@irtf.org<mailto:din-leave@irtf.org> Attachments: * signature.asc _______________________________________________ Din mailing list -- din@irtf.org<mailto:din@irtf.org> To unsubscribe send an email to din-leave@irtf.org<mailto:din-leave@irtf.org>
- [Din] next steps for DINRG Dirk Kutscher
- [Din] Re: next steps for DINRG Chad Kohalyk
- [Din] Re: next steps for DINRG Thomas Hardjono
- [Din] Re: next steps for DINRG 김우태(Operation연구TF)
- [Din] Re: next steps for DINRG Re: 202410191733.A… Abraham Y. Chen
- [Din] Re: next steps for DINRG Lixia Zhang
- [Din] Re: next steps for DINRG Lixia Zhang
- [Din] Re: next steps for DINRG William Lehr
- [Din] Re: next steps for DINRG Thomas Hardjono
- [Din] Re: next steps for DINRG Re: 202410191733.A… Lixia Zhang
- [Din] Re: next steps for DINRG eburger-l@standardstrack.com
- [Din] Re: next steps for DINRG Lixia Zhang
- [Din] Re: next steps for DINRG Christian Huitema
- [Din] Re: next steps for DINRG Jon Crowcroft
- [Din] Re: next steps for DINRG William Lehr
- [Din] Re: next steps for DINRG Thomas Hardjono
- [Din] Re: next steps for DINRG Re: 202410191733.A… William Lehr
- [Din] Re: next steps for DINRG Re: 202410191733.A… Jens Finkhäuser
- [Din] Re: next steps for DINRG Dirk Trossen
- [Din] Re: next steps for DINRG Dirk Trossen
- [Din] Re: next steps for DINRG Re: 202410230956.A… Abraham Y. Chen
- [Din] Re: next steps for DINRG Re: 2024110211733.… Abraham Y. Chen
- [Din] Re: next steps for DINRG Re: 202410231010.A… Abraham Y. Chen
- [Din] Re: next steps for DINRG Re: 2024110211733.… William Lehr