Re: [arch-d] On the (f)utility of prescriptive architecture

Jared Mauch <jared@puck.nether.net> Sun, 22 March 2020 15:36 UTC

Return-Path: <jared@puck.nether.net>
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 187543A0888 for <architecture-discuss@ietfa.amsl.com>; Sun, 22 Mar 2020 08:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 NOr8KV7qIm0I for <architecture-discuss@ietfa.amsl.com>; Sun, 22 Mar 2020 08:36:35 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E5B3A0878 for <architecture-discuss@ietf.org>; Sun, 22 Mar 2020 08:36:35 -0700 (PDT)
Received: by puck.nether.net (Postfix, from userid 162) id CC1CB540310; Sun, 22 Mar 2020 11:36:34 -0400 (EDT)
Date: Sun, 22 Mar 2020 11:36:34 -0400
From: Jared Mauch <jared@puck.nether.net>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: "Brian Trammell (IETF)" <ietf@trammell.ch>, Toerless Eckert <tte@cs.fau.de>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Message-ID: <20200322153634.GB1260110@puck.nether.net>
References: <2A2794D3-25C5-4259-AF5D-098671A786C7@trammell.ch> <0B3B71EE-F5BB-45F0-84EA-ECF454921648@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0B3B71EE-F5BB-45F0-84EA-ECF454921648@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/2HZmK530_-SvQ5Fsj0gaCtIcmvo>
Subject: Re: [arch-d] On the (f)utility of prescriptive architecture
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: Sun, 22 Mar 2020 15:36:37 -0000

On Sun, Mar 22, 2020 at 09:19:14AM +0000, Stewart Bryant wrote:
> 
> 
> > On 21 Mar 2020, at 15:21, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
> > 
> > Hi Stewart, all,
> > 
> > I’ll leave the question of the appropriateness or this side meeting announcement to the side, but I did want to respond to the notion that the IAB should have some top-down master plan for the Internet, and that the lack of such is evidence that the IAB is not properly tracking changes in the Internet itself.
> > 
> > Architectural guidance from the IAB has admittedly been somewhat meta: 5218, 6709, and 8170 on how protocols themselves emerge and evolve in a multi-protocol, multi-implementor, multi-operator environment; 6973, 7754, and 7624 on privacy, access control, and confidentiality concerns of protocols up the stack; 8546 and 8558 on the implications additional confidentiality on the wire has on transport design and operations, and so on. Each of these efforts has been in parallel to related efforts in the IETF (I would argue that the design and deployment of QUIC, for instance, is influenced, in some cases deeply, by all of the cited RFCs).
> 
> 
> Maybe I have missed it, but I have not seen any IAB work with the community on the de facto fundamental restructuring of the Internet into a series of walled gardens with best effort global traffic on a path to become a minority interest.
> 
> For those that have not noticed it, I recommend reading Geoff Hustons work on the death of transit. This points to a huge elephant that is sitting on the middle of the room that we completely ignore.
> 
> Even if the IAB is not able to directly design the architecture of the Internet, it ought to at least be the body that reminds us all what it actually is, and provides some insight into both the opportunities and the threats.
> 

	I live much of this daily and am working with our internal teams to 
cope with the changes in the industry on a regular basis.  We ourselves
built our own backbone to get around regional networking issues that many
are aware of.  It's often in our economic advantage to take our fate into
our own hands for a number of reasons:

  1) networks have no incentive to ensure they have off-network connectivity
  2) networks have no incentive to improve off-network performance
  3) networks have no incentive to lower costs, or can be immune to what
     might be otherwise market pressures.
  4) content providers and delivery networks have paying customers who
     outsource fixing or working around the problem.
  5) private networks have better performance than public networks
  6) private networks are harder to measure than public networks
  7) we can understand the properties of our own private network and deploy
     non-standard fixes to our problems (eg: SR, BGP-LU) that have zero place
     in public networks
  8) costs are significantly lower in a private network vs public

	For these reasons amongst others, it's been in my employers best
interest to privatize traffic, but this has consequences that impact
existing models.

	While Geoff is often right IMO, he's also wrong.  Transit is dead,
long live transit.  You may reach your VPS with a single network hop
from your broadband service directly peering with your cloud provider,
they still rely on transit services to reach networks they do not interconnect
with.  We have the same situations and often hear from providers when
we start using paid transit links that can't handle the load due to #1 or #2
above.

	I have observations about how global players do better than what
I call the super-regional players (eg: multi-market incumbents that do
not span country boundaries).  If someone exists in many countries or
continents, they are more likely to be well suited for traffic vs
someone who owns a market.

	Building last mile is expensive, I can tell you this first hand
as my side job is running a small FTTH network.  It's also very rewarding
if you can adapt to the local market conditions.

	I expect that my perspective on many of these things contributed
to why my virtual badge has a dot on it starting later this week.  It's
something I care about and suspect I'll bring this perspective to the
table in a way others perhaps haven't.

	- Jared