Re: [arch-d] possible new IAB programme on Internet resilience

Dan York <york@isoc.org> Wed, 01 January 2020 18:44 UTC

Return-Path: <york@isoc.org>
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 B3EE91200C4 for <architecture-discuss@ietfa.amsl.com>; Wed, 1 Jan 2020 10:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org
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 etsbHuW762w8 for <architecture-discuss@ietfa.amsl.com>; Wed, 1 Jan 2020 10:44:24 -0800 (PST)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2066.outbound.protection.outlook.com [40.107.220.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E420120044 for <architecture-discuss@iab.org>; Wed, 1 Jan 2020 10:44:24 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oECpuPIkGLbduYrOEaS839TQETxABbsB6Q9JG3+qHJrk11zkUgKmtNh9wvPoDskqNu+pSzoaG54CXSyrTdeIdmarvwuNbwYQ+iIzYc0EwR0vX4bA5+Zk/PfRRLs8CffGi2soINEfPkMnRnESeino23WBtaAuZ/r+9sIFJibV0u/jDLHMwgKbnczgBDhvKR2FlwgewnNMSZp30j6Wzm+1IA/nSamjsuVk4v7salRZHn/9hnpYf0aASLAbfJOTm/WRERQHBv5t3AQlGeemxuc+qfJNzLvI9qKfol3hFS49+uTpoQphkjXkN0+CEPbHZDKfsF+gZl5MBeV6fpi4Hxo14Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O9gRW+0rMQVClRv1BjYWIcBmk3q37RHdd04guoXQjug=; b=lXogYI5HLdkmL5ZEq672PYuBNRYChrgnt3GtKS9U6qEmmAh/l8uwR3sN1CN3NhWJojR+9U1xJnxihebPpriyOPs7it0lPmitLl6Cy1NZ90Sx288rQRF2FkgpGyeBP5/2lOfJ38PTko6eXDrgoUkQ6jmWxY1nqFrQcfESh2dLRvrGXw3BS1q7vrUsRcbeZwoSsxS9faspjSrrUn8IVryYiicsptO0Rm1utU/yy4b9UddFSWTBkFq9D/JpQkJ0GXi0AHUjENM4nBgVAaZjxdJF36DNvTHuqAuF4wnc2vvxWMtagLGvr7vgSgY3GEQzBK0DnifESUco+DQvG/r9UPc1uA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O9gRW+0rMQVClRv1BjYWIcBmk3q37RHdd04guoXQjug=; b=uaUYJo/79fbIHNZPSfGoQ6fCX6oQnp6tDUmIQKd0BEkfKRn60aFhu1WavTOlNiQbwaOHM1FfNnhoia1UrCWhWVQQGqazEw6yqwwivRaRl4f93jAmTf7QI8ew7lDk1w+rFziQ6JOcQgypvmJB7EQzIMMTM69fC3j4QxVHJjFXIoo=
Received: from DM5PR06MB2649.namprd06.prod.outlook.com (10.168.199.143) by DM5PR06MB2778.namprd06.prod.outlook.com (10.175.107.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.12; Wed, 1 Jan 2020 18:44:22 +0000
Received: from DM5PR06MB2649.namprd06.prod.outlook.com ([fe80::2c2d:4ecc:c8f0:115d]) by DM5PR06MB2649.namprd06.prod.outlook.com ([fe80::2c2d:4ecc:c8f0:115d%5]) with mapi id 15.20.2602.010; Wed, 1 Jan 2020 18:44:22 +0000
From: Dan York <york@isoc.org>
To: Lucy Lynch <llynch@civil-tongue.net>
CC: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "architecture-discuss@iab.org" <architecture-discuss@iab.org>
Thread-Topic: [arch-d] possible new IAB programme on Internet resilience
Thread-Index: AQHVtzoIc/E2h2BESU61KFOCTP34h6fUsiuAgAGGVQA=
Date: Wed, 1 Jan 2020 18:44:21 +0000
Message-ID: <7020A5C7-6D06-4D6B-85DD-3FCE9CFC03C7@isoc.org>
References: <f13e1588-35e0-2493-93d2-add3480bb207@cs.tcd.ie> <alpine.BSF.2.21.99999.352.1912311910270.24431@hans.rg.net>
In-Reply-To: <alpine.BSF.2.21.99999.352.1912311910270.24431@hans.rg.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org;
x-originating-ip: [2601:198:4100:84b0:413e:b645:50a0:2e94]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3a89214e-748a-49bb-6810-08d78eea9dfe
x-ms-traffictypediagnostic: DM5PR06MB2778:
x-microsoft-antispam-prvs: <DM5PR06MB27782A47127202A6EA549706B7210@DM5PR06MB2778.namprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02698DF457
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39840400004)(396003)(136003)(366004)(189003)(199004)(53546011)(81166006)(66476007)(66446008)(66946007)(64756008)(33656002)(4326008)(2906002)(76116006)(8936002)(2616005)(36756003)(6506007)(86362001)(45080400002)(81156014)(71200400001)(66556008)(186003)(8676002)(91956017)(5660300002)(66574012)(508600001)(6486002)(966005)(6916009)(54906003)(316002)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR06MB2778; H:DM5PR06MB2649.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: K5abxhXHwHsSnO5kxsMsOR+KHRWBFMul50tpzocKn8/pbURhvX62n1mhWdosAoKjrKLD3KVhPv9wWrKLGxtcJAX78rKAtI0A1UYXbqMBNFKIG/ugYAbsZJCfHvvNt5/d7AHMpfTqz+l4mxepNM16X6Bl4p/O3qmWP112NXgg+MxP/yQv3OAmRD7gHxxAfU/USa/Q/mrJpy7o1qD8g0CTldEVLvoOavtHmndlcwuXJBTXlHRXVrfAfL13AKpKJHzRWkrUzI9o6J0Q2UPxz5Bw8a3teprgW8lphOMwahsEzuoCfx57TC/fLYNzXzvv3jmkmscMVrXsNOKbKevKUbsi5lUE1gQRP9INQA/PBW18q8qA6zdAjHvCBRJr47M59ZneCAsCgaqcEv6uLXzf+yPtEZDG8ovMfrFibtltEdpJF7ocxdD2tnXdmC4koaQawIXP9EiNBWPcQNHdxgOQcDizl0fQQWtp0UcS/5FvPDI7Wzg=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_7020A5C76D064D6B85DD3FCE9CFC03C7isocorg_"
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a89214e-748a-49bb-6810-08d78eea9dfe
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jan 2020 18:44:21.7962 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: juf1ec/srIYasbN4BU9CUVPwMAKPUBZWNPB7/3rit364GsE+lz1i6C1FT2M6rJlY
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB2778
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/QJghNXamipB96vqPZDpXTWj2ge8>
Subject: Re: [arch-d] possible new IAB programme on Internet resilience
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: Wed, 01 Jan 2020 18:44:28 -0000

Stephen,

Lucy very nicely captured a concern I’d had… upon which I expanded a bit below..

On Dec 31, 2019, at 2:27 PM, Lucy Lynch <llynch@civil-tongue.net<mailto:llynch@civil-tongue.net>> wrote:

On Fri, 20 Dec 2019, Stephen Farrell wrote:


[1] https://github.com/intarchboard/resilience/


Circling back to the top here.

I think this is a fine topic for an IAB program and I took the
draft charter to encompass resilience as both a technical and a
design problem.

I also agree that this seems to be a great topic for an IAB program.

I am particularly interested in this statement:
----
Definition of resilience:

1]  the capability of a strained body to recover its size and shape
   after deformation caused especially by compressive stress
2]  an ability to recover from or adjust easily to misfortune or change

This program is mostly interested in definition #2.
----
I actually have my own concerns related to #1 as well and would hope that this program might consider the warping of the overall Internet model to accommodate currents trends or business practices.

As an example - an Internet optimized for the web may not be the same
internet that supports real time data collection and shared computation in the context of big science. How do we avoid closing out capabilities as we optimize for others? Narrowing of choices looks like a path to a limited and more brittle model to me.

I agree with Lucy’s example… and would also note that other sources of “compressive stress” could be the increasing movement of most all real-time communication via voice and video to be over the Internet, and most recently the very large movement of streaming online gaming, which has very different characteristics and stress factors (as noted in recent discussions in the new MOPS working group and the BOF before it).

I like Lucy’s phrase "the warping of the overall Internet model to accommodate current trends or business practices,” particularly when some of those current business practices may involve connecting networks not only to the public Internet, but also to private, proprietary, globe-spanning networks.

For example, at Amazon’s recent re:Invent conference they promoted a way to directly connect enterprise data centers to Amazon’s global AWS network (“Outposts”) and also a way to connect telco points-of-presence to Amazon’s network (“Wavelength”). My understanding is that Microsoft has similar functionality for Azure (“Stack”, I believe) and Google either has or is working on something similar for their Google Cloud Platform. Similarly, large entities such as Facebook and Netflix have built their own global, private networks that interconnect to local data centers (where those data centers are also connected to the public Internet).

All of these separate, private, global networks are designed to help speed access to content, applications, etc., through caching, “edge” computing, and other technologies. Thinking as a network engineer about running applications in various cloud providers, I can see the value that could be obtained by these connections. And some of these providers are typically promoting these services as providing a low-latency alternative to sending traffic across the public Internet.

Going back to the draft charter text ( https://github.com/intarchboard/resilience/ ) , I note this:

> One fundamental pattern contributing to Internet resilience is diversity: for example, diversity of physical links, of peer networks, of paths through the network. Lack of diversity is a key challenge for Internet resilience.

What if there winds up being a lack of diversity of paths through the “open” and “public” Internet? What if increasingly traffic winds up traveling through these proprietary global networks (to which you need to pay to connect and through that gain permission to send traffic - and only to that company’s platforms)?

Given that the Internet has always been a “network of networks”, there have been (and still are) multiple large, global networks to which you could connect your network and data centers. You may, in fact, connect to multiple of those large, global ISPs to have a higher degree of “resilience” for your network. The difference to me is that in connecting to those network providers (and paying to do so), you are connecting to the open, public Internet.

In contrast, connecting to these newer private networks gives you only access to the company’s cloud or content platform. It’s not the whole Internet.

So regarding definition #2, how does this evolution in network connectivity impact the overall resilience of the Internet to recover from issues?

I think it’s a very interesting question to consider as part of this program.

My 2 cents,
Dan

P.S. And yes, I’m well aware that some large enterprises also operate their own private, global networks / WANs to interconnect their own data centers - and have done so for many years. I think the difference is one of scale. The new “cloud” providers are operating networks significantly larger than any individual enterprise - and are also encouraging enterprises to move away from operating their own networks and to instead move their networking to these newer networks.