Re: [arch-d] On the (f)utility of prescriptive architecture
Marie-Jose Montpetit <marie@mjmontpetit.com> Sun, 22 March 2020 13:14 UTC
Return-Path: <marie@mjmontpetit.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 8E1B53A07BC for <architecture-discuss@ietfa.amsl.com>; Sun, 22 Mar 2020 06:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.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 b_Cavn3rrZI1 for <architecture-discuss@ietfa.amsl.com>; Sun, 22 Mar 2020 06:14:52 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1553A078A for <architecture-discuss@ietf.org>; Sun, 22 Mar 2020 06:14:52 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id q9so11331242iod.4 for <architecture-discuss@ietf.org>; Sun, 22 Mar 2020 06:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=NnScidFdwOCI4Y/tr+pR5c5GpAgF3BVqVe8/80eHGmk=; b=D4t2fNpbdFYUUpBjkXPlgimzr+u4XvRr1RinFrX5ULyHGGoLhY1frk1e04jjy1ZQP0 MkJ/gVpU4iM4VRVHLksUxXGgl6XBJi3BGzJbwH2V8ehh0ly0jksPE7+NBOBhq+wwOZ/u fNnsJGzfc8lnixfKgSGYmAmnBwhgpYnGl/PLKOxIKWSXYrgCMPRs5oyqgrnz7Z/LUzbN Z6OXJ04iaKxUZgopquzeSF4hkaXhu6gCpNNIh9aztYkHyv4IXwGQY4Xu9KSiIiJk56Db 6U3f0yx/Q20wY+MVbiWRucLK2SQ/hlb4yUm/09yYAJntkQpZnYTsJmC7yHylgdHTYbP/ M9fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=NnScidFdwOCI4Y/tr+pR5c5GpAgF3BVqVe8/80eHGmk=; b=iJSDAfkHmN6rAqdyS4B+xMsuD4HvyJXjhowiKLOgZKsqpnADxEUE43GMXtU/kpIG/T CXq9aU7ptOkC523fCYsT+A7+pqYd5y2I9yoDfLxvXVb36A52Rz6LJZa3cptxg2raWpqp hnArLT6ZD807o1KM4WNf+Oa1zB2xUM3C4sE9pSTJ4LZrVkkG506nhRNcv0ODcc53Ilg2 bu5Kv5tAiBqz+yn3RLEbd1olwZcHcaTSs6OGDyCgTvgRc6qynboaVdI3IyLD9DX7jkyj vxdwf7kJTP1ryn51qSiYkZNrmrLQRk6av/J/BjbqjC+aCcm8MlRwtcyU3uny3f/NSlUW 7zGA==
X-Gm-Message-State: ANhLgQ05dVF51vj+lgoNoovl9EUTrkWQsIfqJH3G662aTkzO5pwtWQwE Cyt/obZkgaXe/0XW4azLl9M4eG83l0RY2gg6l+6i/Q==
X-Google-Smtp-Source: ADFU+vvArFkh1E7zA6yHHC+C0ParqHMC87UU2ykBso6ir5ByeRTkbe8R/2Z1CONOZUK8RPxheWmFxJ+mQUlSAtTZ0vw=
X-Received: by 2002:a5e:930a:: with SMTP id k10mr15331589iom.132.1584882891389; Sun, 22 Mar 2020 06:14:51 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 22 Mar 2020 09:14:50 -0400
From: Marie-Jose Montpetit <marie@mjmontpetit.com>
In-Reply-To: <0B3B71EE-F5BB-45F0-84EA-ECF454921648@gmail.com>
References: <2A2794D3-25C5-4259-AF5D-098671A786C7@trammell.ch> <0B3B71EE-F5BB-45F0-84EA-ECF454921648@gmail.com>
MIME-Version: 1.0
Date: Sun, 22 Mar 2020 09:14:50 -0400
Message-ID: <CAPjWiCQ7Xr=GQk8zA_i1M+SAtKeTLKCF9Usp8NHC=VyJqA4=9A@mail.gmail.com>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, Stewart Bryant <stewart.bryant@gmail.com>
Cc: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, Toerless Eckert <tte@cs.fau.de>
Content-Type: multipart/alternative; boundary="000000000000c089e605a1714dbe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/aALxoua8mafV1_xZ1ZDFxnwlu1c>
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 13:14:56 -0000
Stewart: I think you that you are a bit unfair about the IETF not being as worthy of 3GPP or IEEE but I will not launch a polemic on this. But I will suggest you may want to be looking at what is happening in the IRTF wrt looking at Internet evolution. I actually smiled at your "We work on the basis that the data plane we designed many years ago is unchangeable” as we are looking at programming that data plane in the COINRG group not changing a few bits in the header. mjm (with my coinrg co-chair hat) Marie-José Montpetit, Ph.D. marie@mjmontpetit.com On March 22, 2020 at 5:20:47 AM, Stewart Bryant (stewart.bryant@gmail.com) 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. >From my perspective, and it is one that we articulate in our draft, the change is very much an opportunity in that it returns the Internet into an Inter-net and provides mechanisms that allow us to divide and conquer the intractable technical, operational and economic problem of advancing the capability of a global scale network. > > True, there is no overarching prescriptive “architecture for the Internet”, because IMO developing such a thing would be a colossal waste of time. In the absence of a lever with which to impose architectural will, in the best case the broad and diverse community that builds and runs the Internet would look at such a thing, maybe read the abstract, say “yeah that’s nice” then go back to the business of keeping things running. What is more useful is descriptive architecture in the small: looking at the way things are and drawing insights toward evolutionary change; the RFCs cited above are all examples of this sort of thing. Those RFCs largely concern things that run over the Internet data paths, not the way the we might align those paths with future needs. There is no Internet equivalent of what 3GPP does, and continues to do for wireless networks. Nor the continuous evolution process that the IEEE has with Ethernet. We work on the basis that the data plane we designed many years ago is unchangeable except in maters of relatively minor detail such as changing the length of an IP address. > > Most of the problems the long history of IP replacements (including the ones I’ve worked on, and continue to work on) over the years have identified aren’t really technical, or at least are not technical in tractably addressable ways (the speed of light and the fact that all operations one can do in a network have strictly nonnegative latency are problems as old and hard as the non existence of perpetual motion machines). Rather, they are issues of inter organizational relationships and business models: rethinking inter domain routing or end to end QoS require an alignment of incentives that seldom emerges organically in a multi operator network. The point we make in the draft, and is one we need to develop in future versions, is that there is an evolution in the Internet architecture that make it feasible to implement change in a way that has hitherto not been possible. Furthermore there is an opportunity for an economic model that supports such change. > If you’d like the IAB to address these authoritatively, you can talk to your friendly local NomCom about appointing some economists, but it’s not clear to me that that’s the best business for the IAB to be in. I had not thought of economists per se, but now you mention it that might be a good idea, We, the IETF do need to understand the economic and, for that matter, governmental (taken from the perspective of a global exert rather than a particular government) impacts of our technical decisions and it would make sense for them to be part of the long term oversight role the IAB is chartered to take. - Stewart > > Cheers, Brian > > Sent from my iPhone > >> On 21 Mar 2020, at 12:11, Stewart Bryant <stewart.bryant@gmail.com> wrote: >> >> ...and also when the IAB fails to drive the changes needed in the Internet to support the evolving applications requirements or to properly track the changes in the Internet itself. >> >> I did kind of think that the IAB would have had a 10 to 20 year evolution plan front and centre of its thinking, but I have never seen any evidence that it regards that to be one of its core responsibilities. >> >> I also thought that the IAB ought to be an enabler of this thought process by encouraging input form others, but rather than that it seems to be a tightly closed community. >> >> ... just saying. >> >> - Stewart >> >> >>> On 20 Mar 2020, at 23:15, Tony Li <tony1athome@gmail.com> wrote: >>> >>> >>> And I hate to see the IAB stomp on discussions. >>> >>> T >>> >>> >>>>> On Mar 20, 2020, at 4:09 PM, Melinda Shore < melinda.shore@nomountain.net> wrote: >>>> >>>> On 3/20/20 3:03 PM, Stephen Farrell wrote: >>>>> AFAIK this is basically an initiative driven by one or >>>>> a small set of vendors. It is not an IAB activity and >>>>> this list is. ISTM somewhat cheeky to cast this as if >>>>> it were sort-of "official" by sending ICS invites to >>>>> this list and suggesting this list be used for follow >>>>> ups. I'm saying that as an individual and have not >>>>> asked other IAB folks what they think, but again >>>>> speaking personally, I'd be much happier if people >>>>> and organisations had a bit more style. >>>> >>>> That was close to my reaction, as well. >>>> >>>> Melinda >>>> >>>> -- >>>> Melinda Shore >>>> melinda.shore@nomountain.net >>>> >>>> Software longa, hardware brevis >>>> >>>> _______________________________________________ >>>> Architecture-discuss mailing list >>>> Architecture-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www.ietf.org/mailman/listinfo/architecture-discuss
- [arch-d] On the (f)utility of prescriptive archit… Brian Trammell (IETF)
- Re: [arch-d] On the (f)utility of prescriptive ar… Stewart Bryant
- Re: [arch-d] On the (f)utility of prescriptive ar… S Moonesamy
- Re: [arch-d] On the (f)utility of prescriptive ar… Marie-Jose Montpetit
- Re: [arch-d] On the (f)utility of prescriptive ar… Jared Mauch
- Re: [arch-d] On the (f)utility of prescriptive ar… Stephen Farrell
- Re: [arch-d] On the (f)utility of prescriptive ar… Ted Hardie
- Re: [arch-d] On the (f)utility of prescriptive ar… Geoff Huston