[Din] Re: next steps for DINRG

Lixia Zhang <lixia@cs.ucla.edu> Mon, 21 October 2024 13:54 UTC

Return-Path: <lixia@cs.ucla.edu>
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 8ADCAC1CAE7F for <din@ietfa.amsl.com>; Mon, 21 Oct 2024 06:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level:
X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cs.ucla.edu
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 LvgzHXPZbi1B for <din@ietfa.amsl.com>; Mon, 21 Oct 2024 06:54:28 -0700 (PDT)
Received: from mail.cs.ucla.edu (mail.cs.ucla.edu [131.179.128.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E93C23A843 for <din@irtf.org>; Mon, 21 Oct 2024 06:54:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 551FE3C011BC5; Mon, 21 Oct 2024 06:54:20 -0700 (PDT)
Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id fjDj9VUm8TFI; Mon, 21 Oct 2024 06:54:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 9BB983C011BDD; Mon, 21 Oct 2024 06:54:19 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 9BB983C011BDD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1729518859; bh=8pbNHvzuTa5G6BQp1MWoKqnjD7UGhNVhCHWeABw5ymg=; h=From:Message-Id:Mime-Version:Date:To; b=e3cGTbc4l67kDvOtsooiCuSHwWYNrjjzPoBt+8pA+Y+HsbWteqGfZBz8+xP3wxaXy MVVGXzO5yj6un08iWcYCbbDZsOM4Zb4cxryUh4OUqgQs9ZaoqwqB8X21Gg194p5eRi YQ1QqZ61gNkM9LBJmhAhsXl7vQOD80euE7G8BuoueGrnfH0aKvjJ1xLBGXQP1qjQoS HGPm1A2mX8QRu0r/zNZV1VrZGY7xkKB0lzt/UJE3sDCKOBIqiQlzGG6+wZCoBngp+h Bfi96YvCIhff17lqn4nugDCIhRnFh/BgTt3JXwNW58Ajvyun6rY7tmUevIo2oCnpST ArQlMy82uXQNg==
X-Virus-Scanned: amavis at mail.cs.ucla.edu
Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 6fDWsz5H2whS; Mon, 21 Oct 2024 06:54:19 -0700 (PDT)
Received: from smtpclient.apple (syn-076-091-005-005.res.spectrum.com [76.91.5.5]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 63E023C011BC5; Mon, 21 Oct 2024 06:54:19 -0700 (PDT)
From: Lixia Zhang <lixia@cs.ucla.edu>
Message-Id: <F0DCA536-FBE4-4292-923A-796977A90052@cs.ucla.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EDFB1E57-FE3E-4478-9750-F94F3EE6D6A6"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\))
Date: Mon, 21 Oct 2024 06:54:09 -0700
In-Reply-To: <BYAPR01MB4391391642D149D59316D9F0CB402@BYAPR01MB4391.prod.exchangelabs.com>
To: Thomas Hardjono <hardjono@MIT.EDU>
References: <18BAB346-D64A-40A3-A29B-9146562E5674@dkutscher.net> <6d66bdb8-b546-40b1-b723-ee8ac80b8adb@app.fastmail.com> <BYAPR01MB4391391642D149D59316D9F0CB402@BYAPR01MB4391.prod.exchangelabs.com>
X-Mailer: Apple Mail (2.3818.100.11.1.3)
Message-ID-Hash: EOBWZ4SULKQSTDAXBSIOZ2YIEPHJD2NW
X-Message-ID-Hash: EOBWZ4SULKQSTDAXBSIOZ2YIEPHJD2NW
X-MailFrom: lixia@cs.ucla.edu
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@irtf.org" <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/j_073TjgjPWRPSG-Ustgh0NtJwI>
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>

Hi Thomas, 

thanks for your great set of questions. 
Just a personal comment: most of your questions seem to me related to one basic question one way or another: what is exactly the definition of "Internet decentralization" that we are aiming at?

I think clarifying this definition would directly answer the questions about VMs vs bare-metal, machine locations etc. This would also indirectly touch on some other questions (e.g. do so-called Web3 systems have bake-in decentralization). 

I also appreciate your suggestion of identifying potential relations between DINRG and some WGs work.

Lixia

> On Oct 18, 2024, at 12:30 PM, Thomas Hardjono <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>