Re: [arch-d] centralization

Eliot Lear <lear@cisco.com> Fri, 12 March 2021 08:49 UTC

Return-Path: <lear@cisco.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0533A12FC for <architecture-discuss@ietfa.amsl.com>; Fri, 12 Mar 2021 00:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBG2FWbqTl1m for <architecture-discuss@ietfa.amsl.com>; Fri, 12 Mar 2021 00:49:23 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFFF3A1236 for <architecture-discuss@ietf.org>; Fri, 12 Mar 2021 00:49:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14462; q=dns/txt; s=iport; t=1615538963; x=1616748563; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ECXPWqKUN0GInRhywsDVm8lA8ZAtRwSI1YYkzHKEdmM=; b=dG0AlQYXmWta0257/yUulZX+a3X8843iXnfb6kfD9EM9UVUtP8ATjv6s 3QI/qqzqF57dJWYyBptSSQa/QjTkNfYYaFX+uwWir1af13p/30LKD5hLD rQ+m1L1oj7IyS5J0/wDQwcCF/RfF7s9JVcJ8QjzMM88f4i7EXDqpoek/P w=;
X-Files: signature.asc : 488
X-IPAS-Result: A0BFAgDrJ0tgjBbLJq1aHAEBAQEBAQcBARIBAQQEAQGCD4MhVgEnEjGEQYkEiD8DgQaTIogdBAcBAQEKAwEBHQEKDAQBAYQJRAKBdCY4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQGGOg2GRAEBAQMBAQEhSQIIAwULCxIGKgICJyIOBhOCcAGCZiEPq0J2gTKFWIRoEIE5gVOFKgGGRUKCC4ERJxyBWkk1PoF+XgEBgSmDTDSCKwSBc2R0EhQPARQbKQOBAgFYDwIrjTKDBgeMR4pSkHmBFIMKgzCBPYJ4iGqLXgMfk2eQGbJAHF6DdQIEBgUCFoFrISyBLTMaCBsVOyoBgj4JNRIZDY4rDQmIYYEfDoQZQAMvOAIGAQkBAQMJjH8BAQ
IronPort-HdrOrdr: A9a23:/peImKinNJNZfmPRagF9r3l/1XBQXlgji2hD6mlwRA09T+Wzna mV7Zcm/DXzjyscX2xlpMCYNMC7LU/02JZp7eAqXIuKcxLhvAKTRr1KzYyn+DH4Hj27y+g178 ddWoxzEsf5A1Q/rcuS2mSFOvIhxNXCz6yyn+fZyB5WIj1CUK1r4wdnBgvzKCQfLzVuPpY3GI GR4cBKvVObCBEqR/6mDXoIVfWrnbP2va/hCCR2ZSIP2U2rhTOs5KWSKWn94j4uFxVS3Lwl7W /J1yv+66nLiYDc9jbsk0nO8p9RhNztjuFmOfXJoM0UJjLw4zzYA7hcZw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,243,1610409600"; d="asc'?scan'208,217";a="34070154"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2021 08:49:18 +0000
Received: from [10.61.144.23] ([10.61.144.23]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 12C8nHsT019119 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Mar 2021 08:49:18 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <0B6A3B48-3E09-4F04-839D-37F2BF747590@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_845AF77C-2AE4-491E-8C09-36BF390911F3"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Fri, 12 Mar 2021 09:49:16 +0100
In-Reply-To: <22ft10hm4r.fsf@floptop.liman.net>
Cc: architecture-discuss@ietf.org
To: Lars-Johan Liman <liman@netnod.se>
References: <AM0PR03MB352225C516C5B8F161289B97E5909@AM0PR03MB3522.eurprd03.prod.outlook.com> <22ft10hm4r.fsf@floptop.liman.net>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-Outbound-SMTP-Client: 10.61.144.23, [10.61.144.23]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/IqFuT8P-F07IPwhu4CkZo5rvMZ4>
Subject: Re: [arch-d] centralization
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2021 08:49:27 -0000

Hi,

In this context, there are two questions to be asked:
What does it mean for the Internet to go down?
What can be done to keep it from going down?
While we often describe the Internet as a network of networks, from society’s perspective, we need a better definition.  A straw man might be this:

The Internet is the sum of the services that are used by the aggregate of users.

In order to keep this message short, I will simply assert that while cloud services can on the whole improve resiliency, when core services go down, the impact is so vast that we simply don’t want to see it happen.  And so I don’t want to spend much time on Q1.  If anyone really wants to debate the point in detail, fine, but otherwise...

That brings us to the 2nd question.  What can be done to improve resiliency?  That is where I think recommendations need to be focused.

Eliot


> On 12 Mar 2021, at 08:22, Lars-Johan Liman <liman@netnod.se> wrote:
> 
> Yaakov,
> 
> Interesting! Thanks!
> 
> I follow much of your argumentation, but I kind of came to a soft halt
> at the end, so, for the purpose of discussion:
> 
>> which means that one large network is worth much more than 2
>> half-sized networks.
> 
> I think this statement should be qualified a bit, because I think one
> parameter is how "worth" is measured. I would argue (and I admit this is
> from gut feeling more than from facts or knowledge, so I will not take
> offence from being contradicted) that a non-functional large network is
> worth less than 2 funcional half-sized networks, at least for some
> purposes.
> 
> My gut feeling tells me that the cost of keeping a centralised system
> consistent rises with its size, and it's probably not linear. Isn't
> there a point where the cost of keeping it consistent and reliable
> exceeds the extra value added by increasing its size by delta-x?
> 
> Or, where the risks of systemic failure overtakes the added value.
> 
> Granted: obviously these points are moving targets, being pushed by
> development, but still?
> 
> The "worth" can be measured not only in short time capital gain, but
> also in risks, no?
> 
>> Over time this pressure can't be resisted.
> 
> Agreed, if measured only in short time capital gain, but maybe it can be
> (at least for longer time) if political backpressure (with less focus on
> capital gain) is applied?
> 
> 				Best regards,
> 				  /Liman
> 
> #----------------------------------------------------------------------
> # Lars-Johan Liman, M.Sc.               !  E-mail: liman@netnod.se
> # Senior Systems Specialist             !  Tel: +46 8 - 562 860 12
> # Netnod Internet Exchange, Stockholm   !  http://www.netnod.se/
> #----------------------------------------------------------------------
> 
>>> Market consolidation and centralization can be good ...
>>> But there are also some serious drawbacks.
> 
> yaakov_s@rad.com 2021-03-11 17:57 [+0000]:
>> Yes. There are often trade-offs and these trade-offs can be analyzed.
> 
>> In response to one remark I pushed into the chat window a remark about the CAP theorem.
>> This theorem is commonly used when analyzing distributed systems,
>> and is directly applicable to networks which are distributed systems
>> for delivery of packets.
> 
>> Basically the CAP theorem says you can't have all three of
>> Consistency, Availability, and Partition (fault) Tolerance.
>> IETF people are used to distributed routing protocols that emphasize A
>> and P at the expense of C
>> (which is why we need a TTL field in the packet header),
>> while computation academics who expect consistency gave us centralized SDN.
>> For databases the two extremes are called ACID and BASE.
> 
>> To enable more nuanced trade-offs networks use both control
>> (distributed) and management (centralized) planes,
>> for example centralized management for policy and distributed control for rerouting.
>> (So, what SDN does is not to introduce a control plane, but rather to
>> replace the control plane by a management plane.)
> 
>> However, when referring to multi-user networked applications (not the
>> communications service)
>> there is strong pressure towards centralization.
>> Why do we have basically one Facebook, one Amazon, etc?
>> Because the value of a network application is super linear (Metcalfe's
>> law puts is a N^2, Reid's law puts it at 2^N)
>> which means that one large network is worth much more than 2 half-sized networks.
>> Over time this pressure can't be resisted.
> 
>> Y(J)S
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss