[Din] Re: next steps for DINRG Re: 2024110211733.AYC Re: 202410191733.AYC

"Abraham Y. Chen" <aychen@avinta.com> Wed, 23 October 2024 13:56 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 2EAB6C1DA1FC for <din@ietfa.amsl.com>; Wed, 23 Oct 2024 06:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.095
X-Spam-Level:
X-Spam-Status: No, score=-0.095 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_FILL_THIS_FORM_SHORT=0.01, 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 NnmsHrSORRkY for <din@ietfa.amsl.com>; Wed, 23 Oct 2024 06:55:55 -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 CE047C1E7246 for <din@irtf.org>; Wed, 23 Oct 2024 06:55:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avinta.com; s=default; h=In-Reply-To:References:Cc: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=D8wF3CfLh7uWn9VtXRDsqeHSfWul+cOEfBR0I9Gpe9o=; b=qzheyDHvyJn+2/+8ZSu1jjw38m d88wGbsRJysL2jcJ7O59wBz9e5QgQeZFSGUYFLcLTYDRtMoEvu31YQc/Ezq8cuSo2ryW9ccVlTgGX 4tA3A6LZciqyw5LwpIgbY8qNi4bWu7ghtvU7a8+jCU/rEapNdrfloCxiTR8UM8pfmKn1btRW+/qxE MuhfwZk8pffMpW36QHhFZB31+0WnC45Y7JSi4bvuD/mmtP4H3koNd/IVHePX3LLSRfaqnQhOMsCZL kvd3BeYK5SpFCKqt3fApDscyoF8By2CXRHQzW755xcnLrGOS6Xw5ezPgcZyXmpRDAWkpouqj4iesS zy8/I0sQ==;
Received: from syn-184-153-001-039.res.spectrum.com ([184.153.1.39]:51515 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 1t3bq4-000BH0-E9; Wed, 23 Oct 2024 09:55:52 -0400
Content-Type: multipart/alternative; boundary="------------LEdhVTy0rR9iT1HHz8QIQgPF"
Message-ID: <09c80842-cd97-4e4f-9122-050db761e24e@avinta.com>
Date: Wed, 23 Oct 2024 09:55:45 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: "Abraham Y. Chen" <aychen@avinta.com>
To: William Lehr <wlehr@mit.edu>
References: <18BAB346-D64A-40A3-A29B-9146562E5674@dkutscher.net> <65eb7bb8-7017-4a4f-a3c0-838e2ebe1887@avinta.com> <79528934-BCED-44CD-A44C-C4440A939771@cs.ucla.edu> <8730a6a0-cb89-45e6-868c-26993453ed4e@mit.edu>
X-Priority: 1 (Highest)
Content-Language: en-US
In-Reply-To: <8730a6a0-cb89-45e6-868c-26993453ed4e@mit.edu>
X-Antivirus: Avast (VPS 241023-0, 10/23/2024), Outbound message
X-Antivirus-Status: Clean
X-MagicSpam-TUUID: 59b07e10-729c-47a6-b477-b3e0d0fd9f7b
X-MagicSpam-SUUID: 00521fc0-528a-4659-bf25-07b1014c1c10
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: 6KRSGQ4OLQGGGOUDQ7EHYVO2GYH2URE2
X-Message-ID-Hash: 6KRSGQ4OLQGGGOUDQ7EHYVO2GYH2URE2
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: Lixia Zhang <lixia@cs.ucla.edu>, Dirk Kutscher <ietf@dkutscher.net>, "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: 2024110211733.AYC Re: 202410191733.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/7GFvGPjmTvUbwOM-khgUOvAnJ4M>
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, William:

0)    Thanks for injecting your thoughts. I am no linguist. So, I may 
get mixed up with the meaning of certain words or expressions. 
Hopefully, we can clarify each relevant ones and define them clearly 
through discussions for the purpose of this Group.

1)    " ... A distributed mechanism may be subject to centralized 
control. ...   ":

     Agreed. This is what CDN has done to the Internet. On the other 
hand, the reverse is true, as well. That is, a centralized mechanism may 
be subject to distributed control. To illustrate, allow me to recite a 
small history. I was in charge of coordinating the MIT-LL ground station 
for the LES8/9 satellite pair nearly half century ago. We had multiple 
antennas on the roofs with various experiments going on in multiple labs 
throughout the buildings. They all shared the same set of signals to and 
from the satellites which meant that we had to have a */centralized 
mechanism to route / distribute/* such. To do so, I designed/*a coaxial 
cable switching relay matrix */located at a strategic /*central*/ 
location with /*identical control and display panels */*/distributed/* 
at every location where might have the need to configure or monitor the 
RF signal paths, at any moment.

2)    " ... Telephone service reliability is enhanced ...":

     Could you elaborate on this? In particular, what "enhanced" the 
telephone service?

3)    "... because failure of PSTN and Internet are not perfectly 
correlated... ":

     When we compare / study two systems, similarity is good enough for 
learning one from the other. Most of the time, we do not have the luxury 
of having perfect correlation between them.

4)    "..  failure of PSTN need not mean failure of ability to make 
phone call. .... ":

     By "failure of PSTN", do you mean some parts of the PSTN equipment? 
If so, you are correct. Otherwise, a system (the entire PSTN) failure 
would definitely be felt by a subscriber making a phone call. On the 
other hand, with multiple redundant paths by design serving as backups, 
strict operation disciplines, plus some tricky user operation 
instructions, PSTN failures as perceived by subscribers were very rare 
(true 7- 9's availability versus Internet's promised 5- 9's).

5)    "  ... may not be known to higher-layer users ...  ":

     I believe what we are looking for is exactly this problem, such as 
the concentration of Internet routing process to DNS in CG-NAT that 
eventually exhibited as the concentration of operations to CDN. These 
results are so general, all the lower level details that you apparently 
are referring to should have been "smoothed" over by multiple levels of 
the "integration" process.

Regards,


Abe (2024-10-21 18:58 EDT)


On 2024-10-21 16:40, William Lehr wrote:
>
> distributed and decentralized often mean two different things. A 
> distributed mechanism may be subject to centralized control.
>
> decentralization has important implications for independence wrt 
> failure modes which impacts reliability. Telephone service reliability 
> is enhanced because failure of PSTN and Internet are not perfectly 
> correlated so failure of PSTN need not mean failure of ability to make 
> phone call.
>
> virtualization allows control and function to be separated in geospace 
> (distributed) that can have implications for performance (e.g., 
> latency, reliability) that may not be known to higher-layer users that 
> may seek to exert centralized control over a system that is 
> distributed, etc.
>
> On 10/21/24 10:17 AM, Lixia Zhang wrote:
>> Hi Abe,
>>
>> I think you brought up a set of very interesting, and also very 
>> important, questions and comments. To me, the top few are:
>>
>>   * "distributed or decentralized": it seems worth clarifying whether
>>     the two words mean the same or different things in the DINRG context.
>>   * the question in Thomas msg showed up again: how much the node
>>     locations matter.
>>   * "we find that Internet users have no permanent identity": this is
>>     a fact, how this fact relates/impacts (de)centralization.
>>
>>
>> To everyone on the list: please share your suggestions about next step.
>> Dirk and I will try our best to summarize and structure all the 
>> suggested discussion topics into Dublin agenda.
>>
>> Lixia
>>
>>> On Oct 20, 2024, at 7:21 AM, Abraham Y. Chen 
>>> <aychen=40avinta.com@dmarc.ietf.org> wrote:
>>>
>>> Dear Dirk:
>>>
>>> 0)    I have been reading the eMail threads and learning the charter 
>>> of this Group for awhile. I would like to start from trying to 
>>> understand your first DINRG objective:
>>>
>>> 1)    " Investigation of the root causes of Internet centralization 
>>> ...  ":
>>>
>>>     Centralization vs. decentralization in a system could manifest 
>>> in surprisingly alternating manners depending on which particular 
>>> perspective that one's investigation is focused upon. For example,
>>>
>>>     A.    During the Internet infancy days, the PSTN (Public 
>>> Switched Telephone Network) was criticized as being too centralized 
>>> implying that the Internet would be distributed or decentralized. As 
>>> this Group agrees, the Internet is now far from being decentralized, 
>>> after all. The reason for this discrepancy is that back then 
>>> colleagues were looking at the network facility to assume that the 
>>> operations would have the same characteristics.
>>>
>>>     B.    Comparing the operations today, we find that Internet 
>>> users have no permanent identity, except temporarily assigned by 
>>> multi-national business conglomerates, thus not able to freely 
>>> communicate with one another, starting from even a neighbor. This 
>>> means that the Internet operation today is a centralized one. In 
>>> contrast, PSTN supports dial-up modems that enable any and every 
>>> user the freedom / flexibility / independence of contacting anyone 
>>> around the world anytime for data communication (This was how the 
>>> Internet initially got popularized, although very slow by today's 
>>> standards) which is clearly a distributed and decentralized operation.
>>>
>>> 2)    The above may sound contradicting that a centralized facility 
>>> supports decentralized operation while a decentralized one operates 
>>> centralized. The fact is that the top layer operational behavior of 
>>> a system determines which way it is from a user's viewpoint. In OSI 
>>> 7 Layer model, as far as I could understand, we should set 
>>> distributed/decentralized as the criterion at OSI Layer 7 for every 
>>> system. Which way the lower Layers appear to be really does not 
>>> matter, as long as they can eventually support the ultimate goal.
>>>
>>> 3)    More specifically, the PSTN core equipment is so centralized 
>>> that the identity of every subscriber loop is predetermined with a 
>>> phone number. So, a CPE (Customer Premises Equipment) can be mass 
>>> produced without the capability to acquire an identification upon 
>>> plugging into a jack at the end of a subscriber loop. Essentially, 
>>> the DHCP operation has already been accomplished in a user's mind. 
>>> In the Internet, however, an IoT has to go through the process of 
>>> acquiring an IP address (yet temporary) from the network core before 
>>> it can operate, which means that an user can not operate 
>>> independently at well.
>>>
>>> 4)    The above may be vague, unorganized, or philosophical. This is 
>>> because I just began to formulate this analytical approach for 
>>> visualizing the problem at hand. I believe that we do need to 
>>> exercise our minds from this angle, or similar to be able to set the 
>>> criteria and priority for qualifying an application or operation. So 
>>> that, we may have some chance to achieve the goal of "decentralizing 
>>> the Internet".
>>>
>>> 5)    Essentially, I believe that if a user does not have a 
>>> permanent identity (static IP address) for communication through a 
>>> system, the operation becomes centralized by having to rely upon a 
>>> focal facility serving the coordination functions.
>>>
>>> I look forward to your thoughts.
>>>
>>> Regards,
>>>
>>>
>>> Abe (2024-10-20 10:21 EDT)
>>>
>>>
>>>
>>> On 2024-10-18 04:41, 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
>>>> To unsubscribe send an email to din-leave@irtf.org
>>>>
>>>
>>>
>>> Virus-free.www.avast.com _______________________________________________
>>> 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 todin-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
>
> ==+==+==+==+==+==+==+==+==+==+==+==+==+



-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com