[Din] Re: next steps for DINRG Re: 202410230956.AYC
"Abraham Y. Chen" <aychen@avinta.com> Wed, 23 October 2024 14:07 UTC
Return-Path: <aychen@avinta.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 811B8C151522 for <din@ietfa.amsl.com>; Wed, 23 Oct 2024 07:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.105
X-Spam-Level:
X-Spam-Status: No, score=-0.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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, URI_DOTEDU=1.999] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=avinta.com
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 SnY_IwzSJZqp for <din@ietfa.amsl.com>; Wed, 23 Oct 2024 07:07:34 -0700 (PDT)
Received: from cp22.lowesthosting.com (cp22.lowesthosting.com [23.111.133.162]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28474C151076 for <din@irtf.org>; Wed, 23 Oct 2024 07:07:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avinta.com; s=default; h=In-Reply-To:Cc:References:To:Subject:From:MIME-Version:Date: Message-ID:Content-Type:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Itx3ih4PW2ApiBSvCKgV6AOl4yQjzJAdDrCrqwWjIks=; b=tspEflLJ5RCnW1GQwjyIxSBChu JUHen3d4irgmIlOgFN3V8NAX0JFKYXzURrhWSiNroMvxuF6G/cGHWNmRrgr6NzAB8VpbSTHdmkY+v GKn1h6cs0UurbN83AVGstEjSKrBXqONGqS4MVT11VqohLeO9K3AFYmrJhJf9eMXmmp8lfx7P3AKI1 4YIZEFSpOQOoBiiTdjmqiS/+9Kfd/G1G6sT+suAscScB4Rwr+c2HqWT4hVLuz96glRCGdhH+ZDpTY PkvTRvLKo66vbgK545szSH5r1JghnbIl3lW+78kRLtUGzlB22ygE35nllHgllzWK2ybJQ0FMAn7Ln OV4TrTlg==;
Received: from syn-184-153-001-039.res.spectrum.com ([184.153.1.39]:51607 helo=[192.168.1.142]) by cp22.lowesthosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from <aychen@avinta.com>) id 1t3c1M-000Knh-PT; Wed, 23 Oct 2024 10:07:32 -0400
Content-Type: multipart/alternative; boundary="------------EwWukJ0YyvVcHoF7rtdCjvyc"
Message-ID: <cea69e5f-780d-4338-9eba-b842f089b810@avinta.com>
Date: Wed, 23 Oct 2024 10:07:28 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: "Abraham Y. Chen" <aychen@avinta.com>
To: Christian Huitema <huitema@huitema.net>
References: <18BAB346-D64A-40A3-A29B-9146562E5674@dkutscher.net> <6d66bdb8-b546-40b1-b723-ee8ac80b8adb@app.fastmail.com> <BYAPR01MB4391391642D149D59316D9F0CB402@BYAPR01MB4391.prod.exchangelabs.com> <F0DCA536-FBE4-4292-923A-796977A90052@cs.ucla.edu> <ac3bea84-aeac-4af2-a956-9cb23511656b@mit.edu> <0E0BA301-F8D4-469F-95F5-0D85F7C14DF5@standardstrack.com> <4a6ffff3-0ca5-4636-849a-6634b5c6a23d@huitema.net>
Content-Language: en-US
X-Priority: 1 (Highest)
In-Reply-To: <4a6ffff3-0ca5-4636-849a-6634b5c6a23d@huitema.net>
X-Antivirus: Avast (VPS 241023-0, 10/23/2024), Outbound message
X-Antivirus-Status: Clean
X-MagicSpam-TUUID: 90b7f7d1-8cb4-44f5-8ef8-48515d06e58b
X-MagicSpam-SUUID: c2fbdd5f-0c0c-4e8b-b065-228276cff66f
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cp22.lowesthosting.com
X-AntiAbuse: Original Domain - irtf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - avinta.com
X-Get-Message-Sender-Via: cp22.lowesthosting.com: authenticated_id: aychen@avinta.com
X-Authenticated-Sender: cp22.lowesthosting.com: aychen@avinta.com
X-Source:
X-Source-Args:
X-Source-Dir:
Message-ID-Hash: LF3QLCIM32FVEQJDS7BHIMDN7BZZ5GWI
X-Message-ID-Hash: LF3QLCIM32FVEQJDS7BHIMDN7BZZ5GWI
X-MailFrom: aychen@avinta.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: "din@irtf.org" <din@irtf.org>, "Chen, Abraham Y." <AYChen@alum.MIT.edu>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Din] Re: next steps for DINRG Re: 202410230956.AYC
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/JSsjw9K09a4AUS47HR25vg2KkGw>
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 Christian: 1) " ... it would be nice if instead of focusing on platforms developments could focus on a few applications. ... ": Fully agreed. I would recommend that any idea (mechanism) brought in front of this Group should first be reviewed according to the potential operation (application) consequences. Only those without any signs of encouraging centralization be permitted to proceed as an action item. Others should try to find more appropriate Working Groups to carry on. Regards, Abe (2024-10-23 10:06 EDT) On 2024-10-22 02:46, Christian Huitema wrote: > The classic economic theory of centralization was all about economies > of scale. Per that theory, the limits to centralization was set by the > increased complexity of the ever larger enterprise. Per the theory, at > some point the conglomerate could not react fast enough, and more > agile competitors would start competing efficiently. > > That classic theory did not take into account network effects, which > reinforce the monopolies. Also, information technology supposedly > makes conglomerates easier to manage -- at least compared to pushing > forms in triplicate and taking the train to go to meetings. The > "identity" issue that Abraham Chem mentioned is an example of these > network effects. > > Decentralized solutions may help mitigate the network effects. That > would mean "commoditizing" a number of platform components -- naming > and discovery, introduction, etc. Din RG may be a good place to > identify these solutions. Then, the community might produce helpful > standards -- similar to what happened with MLS. And applications will > use them. Maybe. > > Also, it would be nice if instead of focusing on platforms > developments could focus on a few applications. The good platforms > components almost come after the application. Developing platforms > before developing applications seems rational, but it almost never > works for software. So maybe identify a couple of applications first... > > -- Christian Huitema > > > On 10/21/2024 2:44 PM, eburger-l@standardstrack.com wrote: >> And let us not forget that there might be economic value in the trust >> value-proposition of distributed networks, which outweighs the simple >> calculation of more expensive capital expense and stupidly more >> expensive operating expense. >> >>> On Oct 21, 2024, at 4:33 PM, William Lehr <wlehr@mit.edu> wrote: >>> >>> RE: "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." >>> >>> There are certainly economic models that argue that efficiency and >>> cost-savings favor centralization, but that is definitely NOT a >>> consensus conclusion since it very much depends on the context. In a >>> dynamic environment centralization may very well be less efficient >>> and more costly. The economic arguments for productive efficiency >>> (cost-savings) often rely on scale economies that are assumed to >>> depend on centralized organization of production. The technical and >>> economic implications of more or less decentralization depend on the >>> context and dimension of performance you are considering. Control >>> (decision-making power), ownership, and Parties bearing >>> costs/benefits may all vary in different degrees with respect to the >>> extent of centralization or decentralization. >>> >>> On 10/21/24 9:54 AM, Lixia Zhang wrote: >>>> 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> >>>>> <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 mailing list -- din@irtf.org <mailto:din@irtf.org> >>>> To unsubscribe send an email to din-leave@irtf.org >>>> <mailto:din-leave@irtf.org> >>> -- >>> >>> ==+==+==+==+==+==+==+==+==+==+==+==+==+ >>> Dr. William Lehr >>> Research Associate >>> Computer Science and Artificial Intelligence Laboratory (CSAIL) >>> MIT Office: >>> Massachusetts Institute of Technology >>> 32 Vassar Street (32-G532) >>> Cambridge, MA 02139 >>> tel: 617-258-0630 >>> fax: 617-253-2673 >>> >>> Home Office (preferred): >>> 94 Hubbard street >>> Concord, MA 01742 >>> >>> cell: 978-618-3775 (preferred) >>> fixed: 978-287-0525 >>> >>> website: http://csail.mit.edu/~wlehr >>> email: wlehr@mit.edu <mailto:wlehr@mit.edu> >>> >>> ==+==+==+==+==+==+==+==+==+==+==+==+==+ >>> _______________________________________________ >>> Din mailing list -- din@irtf.org >>> To unsubscribe send an email to din-leave@irtf.org >> >> >> _______________________________________________ >> Din mailing list -- din@irtf.org >> To unsubscribe send an email to din-leave@irtf.org > > _______________________________________________ > Din mailing list -- din@irtf.org > To unsubscribe send an email to din-leave@irtf.org -- This email has been checked for viruses by Avast antivirus software. www.avast.com
- [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