Subject: Re: [arch-d] centralization

From: "Hutchison, David" <[email-masked]>
Date: Fri, 12 Mar 2021 11:44:34 +0000

Hello everyone,

Of course, I agree resilience is an important topic to pursue -- and like Toerless I was disappointed to see the previous "lukewarm" response ...

There are lots of aspects to resilient systems, including policy but also human and organizational issues, that need to be folded in alongside the technology areas with which most of us are more comfortable. And there are related communities with the know-how, some of these being in sociology, and also in management schools. I see resilience coming up frequently nowadays as an important goal, for example in "smart cities" research where inter-dependent networks and cascading effects of failures are key topics; this also includes networks of autonomous vehicles and emerging electricity supply networks. 

Here is a just-published book that you may find interesting:
https://global.oup.com/academic/product/multisystemic-resilience-9780190095888?cc=ca&lang=en&#
(Above the price on the right hand side of the page is the OPEN ACCESS link where a pdf of the book can be downloaded.)

A more technically-focused book majoring on communications resilience, published fairly recently, is the following:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flink.springer.com%2Fbook%2F10.1007%2F978-3-030-44685-7&amp;data=02%7C01%7Cd.hutchison%40lancaster.ac.uk%7C42821b556a734668d72e08d8346592fb%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637316958146012761&amp;sdata=dA%2FIGedX%2BGznzQg9ka8nqbHyqtgmf8%2F9Kef4BhA4Ksw%3D&amp;reserved=0

Best wishes,
David

...

On 12/03/2021, 10:42, "Architecture-discuss on behalf of Toerless Eckert" <[email-masked] on behalf of [email-masked]> wrote:

    Eliot, *:

    agree and continuing down the rabbit hole:

    Stephen had started a thread and even i think a mailing list about
    resilience, but the response was hmm. is "lukewarm" more PC than "lame" ? ;-)

    So, 2 high level points:

    I raised the question a short while ago, but with Stephen gone from IAB,
    i would first like to raise the question how we could make any form
    of organized work about resilience more resilient against arbitary
    leadership changes (a problem i primarily attribute to the way IAB
    activities are often structured).

    I also think that as much fun as resilience at the technical level we
    do and would like to work and document on is, i fear that there is a lot
    more aspects to resilience at the policy level that are very important,
    and unlike privacy and language we don't seem to have attracted a
    community interested to work on the policy level AND know how to do it.
    Maybe there is some outreach to be done to ISOC and/or even HRPC might
    be a good place to look for advise to foster work on that layer.

    Cheers
        Toerless

    On Fri, Mar 12, 2021 at 09:49:16AM +0100, Eliot Lear wrote:
    > 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 <[email-masked]> 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: [email-masked]
    > > # Senior Systems Specialist             !  Tel: +46 8 - 562 860 12
    > > # Netnod Internet Exchange, Stockholm   !  https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.netnod.se%2F&amp;data=04%7C01%7Cd.hutchison%40lancaster.ac.uk%7C974cd91ddd4348da4d2808d8e54376e8%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637511425204958861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=mSAvz1Uz1wkvJ5IHVn0K1cAO8mdyXXFag0x4nw0kU7o%3D&amp;reserved=0
    > > #----------------------------------------------------------------------
    > >
    > >>> Market consolidation and centralization can be good ...
    > >>> But there are also some serious drawbacks.
    > >
    > > [email-masked] 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
    > > [email-masked]
    > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Farchitecture-discuss&amp;data=04%7C01%7Cd.hutchison%40lancaster.ac.uk%7C974cd91ddd4348da4d2808d8e54376e8%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637511425204958861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=R0%2F%2FPvdOjkfzshBQ4%2FDNIoF4FUSpxBNVjXiPhbgncSc%3D&amp;reserved=0
    >

    > _______________________________________________
    > Architecture-discuss mailing list
    > [email-masked]
    > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Farchitecture-discuss&amp;data=04%7C01%7Cd.hutchison%40lancaster.ac.uk%7C974cd91ddd4348da4d2808d8e54376e8%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637511425204958861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=R0%2F%2FPvdOjkfzshBQ4%2FDNIoF4FUSpxBNVjXiPhbgncSc%3D&amp;reserved=0

    --
    ---
    [email-masked]

    _______________________________________________
    Architecture-discuss mailing list
    [email-masked]
    https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Farchitecture-discuss&amp;data=04%7C01%7Cd.hutchison%40lancaster.ac.uk%7C974cd91ddd4348da4d2808d8e54376e8%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637511425204958861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=R0%2F%2FPvdOjkfzshBQ4%2FDNIoF4FUSpxBNVjXiPhbgncSc%3D&amp;reserved=0

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 12 Mar 2021 12:33:29 +0000

Hiya,

On 12/03/2021 11:44, Hutchison, David wrote:
> 
> Of course, I agree resilience is an important topic to pursue -- and
> like Toerless I was disappointed to see the previous "lukewarm"
> response ...
Yeah, me too. It was funny that we had a good discussion
on this list around the end of 2019 but then once we
started a new list [1] it totally died. My conclusion
was that indicated that people were interested in chatting
but not in doing actual work on this topic.

S.

[1] https://www.iab.org/mailman/listinfo/chirp

---

From: Eliot Lear <[email-masked]>
Date: Sun, 14 Mar 2021 11:45:53 +0100

Hi Stephen,

I think that’s the wrong conclusion to draw, especially given events of the last year.  In fact, I myself missed some pretty important work that came out on this topic, which I believe ISOC actually advertised/sponsored[1].  IMHO there are limited aspects of concentration that the IETF can take on, but the IAB would be quite remiss to not engage  in this sort of activity, given the risks to the Internet.

What can the IAB do?  The problem here is that there is movable feast.  We can look through the prism and see cybersecurity risks, or we can see resiliency risks, and of course the two are related.

The board can bring relevant people together like, Geer, Jardine, Leverett, Radu and Hausding, along with software service providers to discuss how to mitigate the risks they described.
Beginning with a workshop
With a potential program or IRTF effort
The board can articulate design recommendations for the IETF in terms of what can lead to more or less centralization.  As I mentioned, I think some of Martin’s work on middle boxes is interesting in this regard, but it’s not the only activity.  How does service orchestration and network management play into all of this?
In coordination with ISOC, the board could discuss concerns with regulators where they see the need to do so.  This is intertwined, IMHO, with the evolving nature of lawful intercept, and probably needs to be handled with some circumspection.
The board can engaged different internet user communities to discuss the risk and what sorts of mitigations should be undertaken.  Do you know that there are large classes of TCP/IP use that do not allow for DNS because of resiliency concerns?  Is that a physical law or a design failure?

There is no shortage of work to be done here.

Eliot

[1] https://www.tandfonline.com/toc/rcyb20/5/1?nav=tocList

> On 12 Mar 2021, at 13:33, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> <OpenPGP_0x5AB2FAF17B172BEA.asc>

---

From: Watson Ladd <[email-masked]>
Date: Sun, 14 Mar 2021 06:39:39 -0700

> but not in doing actual work on this topic.

I'm not sure what that work would look like. A lot of what makes resilience
is operational and engineering lessons that get shared in a very different
community and that are very implementation specific.

That isn't really the IETF's strength or audience. It's certainly an
important topic.

> https://www.ietf.org/mailman/listinfo/architecture-discuss

--
Astra mortemque praestare gradatim

---

From: Jari Arkko <[email-masked]>
Date: Sun, 14 Mar 2021 18:57:23 +0200

This is maybe a side track for the original thread, but:

> started a new list [1] it totally died

As discussed in the Covid-19 workshop, there’s quite a lot of even consumer interest in network resiliency and reliability as a result of the pandemic situation.

Jari

---

From: Dominique Lazanski <[email-masked]>
Date: Mon, 15 Mar 2021 08:19:49 +0100

Just to say that I completely support Eliot’s suggestions here and though I’ve been thinking about the same points, he has articulated them much better than I could.

I think this issue would attract more than interest and new people into the work which would be great. I, for one, am willing to do work and work collaboratively to put together meaningful outputs that reflect all sides of the debate.

Dominique

> On 14 Mar 2021, at 11:45, Eliot Lear <lear=[email-masked]> wrote:
> 
> Hi Stephen,
> 
> [1] https://www.tandfonline.com/toc/rcyb20/5/1?nav=tocList <https://www.tandfonline.com/toc/rcyb20/5/1?nav=tocList>
> 
>> On 12 Mar 2021, at 13:33, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> Hiya,
>> 
>> [1] https://www.iab.org/mailman/listinfo/chirp <https://www.iab.org/mailman/listinfo/chirp>

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Tue, 16 Mar 2021 21:28:15 +0700

Dear architecture-discuss,

To share what might be inspiring:

Centralization, Concentration and Consolidation

In 2019 ISOC Global Report, Andrew Sullivan the president mentioned about
concentration and consolidation --and supposedly centralization--  in
relation to the Internet Architecture:

"All of these patterns are observable on the Internet today. Each has the
potential to alter how the Internet works, and together they may represent
a challenge to the traditional Internet architecture. They may change what
sorts of development we should expect.

...

This Global Internet Report tells us that the Internet Society has a great
deal of work to do. We must understand what concentration and consolidation
on the Internet mean, both for its architecture and for the wider society
that depends on the Internet. We must understand what is really happening
to the Internet in order to ensure that we build the Internet for everyone".

Yet, precisely 5-6 years ago, there were such architectural concerns about
"All that is solid" --which we may eloborate as ones adaptable and
analogeous as it is about ones which are solid including their moments of
togetherness or consolidation:

"This symposium, the first event in the series 'All that is Solid...',
interrogates the motivations, instruments, influences, justifications,
effects and origins of contemporary design techniques". (2014)

Watch "Symposium on Architecture: "Design Techniques"" on YouTube
https://youtu.be/Zpk5s9di04o

"... the second event of the series 'All that is solid ...' interrogates
collectivity, authorship, effects and development of contemporary design
techniques". (2015)

Watch "Symposium on Architecture: "Design Techniques II," with..." on
YouTube
https://youtu.be/YJ499QtXT8w

Regard,
Guntur Wiseno Putra

Pada Senin, 15 Maret 2021, Dominique Lazanski <[email-masked]>
menulis:

> Just to say that I completely support Eliot’s suggestions here and though
> I’ve been thinking about the same points, he has articulated them much
> better than I could.
>
> I think this issue would attract more than interest and new people into
> the work which would be great. I, for one, am willing to do work and work
> collaboratively to put together meaningful outputs that reflect all sides
> of the debate.
>
> Dominique
>
> I think that’s the wrong conclusion to draw, especially given events of
> the last year.  In fact, I myself missed some pretty important work that
> came out on this topic, which I believe ISOC actually
> advertised/sponsored[1].  IMHO there are limited aspects of concentration
> that the IETF can take on, but the IAB would be quite remiss to not engage
>  in this sort of activity, given the risks to the Internet.
>
> What can the IAB do?  The problem here is that there is movable feast.  We
> can look through the prism and see cybersecurity risks, or we can see
> resiliency risks, and of course the two are related.
>
>
>    - The board can bring relevant people together like, Geer, Jardine,
>    Leverett, Radu and Hausding, along with software service providers to
>    discuss how to mitigate the risks they described.
>       - Beginning with a workshop
>       - With a potential program or IRTF effort
>    - The board can articulate design recommendations for the IETF in
>    terms of what can lead to more or less centralization.  As I mentioned, I
>    think some of Martin’s work on middle boxes is interesting in this regard,
>    but it’s not the only activity.  How does service orchestration and network
>    management play into all of this?
>    - In coordination with ISOC, the board could discuss concerns with
>    regulators where they see the need to do so.  This is intertwined, IMHO,
>    with the evolving nature of lawful intercept, and probably needs to be
>    handled with some circumspection.
>    - The board can engaged different internet user communities to discuss
>    the risk and what sorts of mitigations should be undertaken.  Do you know
>    that there are large classes of TCP/IP use that do not allow for DNS
>    because of resiliency concerns?  Is that a physical law or a design failure?
>
>

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Tue, 16 Mar 2021 22:43:53 +0700

Of the adaptable and analogeous in relation with the two presentations by
Harvard University Graduate School of Design on "All that is solid ..." and
the Internet Architecture above may be confirmed by Prof. Onur Mutlu (ETH
Zurich)'s lecture on "Computer Architecture resembles Building
Architecture" --though in my reading the term "building" is also about
"computer as a building" considering "architecture as art and science of
building" (Oxford English Dictionary) while Prof. Mutlu differed the two as
he referred the latter to be house and the likes.
(A serial Lecture "Digital Design and Computer Architecture"(spring 2020)
Lecture 1 "Introduction and Basics", minutes 1:22:00-1:34:00 and Lecture 2a
Course Goal and Logistics 1:00- 12:00)

Watch "Digital Design & Computer Architecture: Lecture 1: Introduction and
Basics (ETH Zürich, Spring 2020)" on YouTube
https://youtu.be/AJBmIaUneB0

Watch "Digital Design & Computer Arch. - Lecture 2a: Course Goals &
Logistics (ETH Zürich, Spring 2020)" on YouTube
https://youtu.be/44B6YmSuk0I

Regard,
Guntur Wiseno Putra

Pada Selasa, 16 Maret 2021, Guntur Wiseno Putra <[email-masked]> menulis:

>> What can the IAB do?  The problem here is that there is movable feast.
>> We can look through the prism and see cybersecurity risks, or we can see
>>    - The board can engaged different internet user communities to
>>    discuss the risk and what sorts of mitigations should be undertaken.  Do
>>    you know that there are large classes of TCP/IP use that do not allow for
>>    DNS because of resiliency concerns?  Is that a physical law or a design
>>    failure?
>>
>>