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

Toerless Eckert <tte@cs.fau.de> Mon, 13 January 2020 15:37 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 BF5A81200F1 for <architecture-discuss@ietfa.amsl.com>; Mon, 13 Jan 2020 07:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 WOx7B3TKo-zu for <architecture-discuss@ietfa.amsl.com>; Mon, 13 Jan 2020 07:37:49 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D146A120033 for <architecture-discuss@iab.org>; Mon, 13 Jan 2020 07:37:48 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D01D4548043; Mon, 13 Jan 2020 16:37:41 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C541B440059; Mon, 13 Jan 2020 16:37:41 +0100 (CET)
Date: Mon, 13 Jan 2020 16:37:41 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Lucy Lynch <llynch@civil-tongue.net>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, architecture-discuss@iab.org
Message-ID: <20200113153741.GH14549@faui48f.informatik.uni-erlangen.de>
References: <f13e1588-35e0-2493-93d2-add3480bb207@cs.tcd.ie> <alpine.BSF.2.21.99999.352.1912311910270.24431@hans.rg.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.BSF.2.21.99999.352.1912311910270.24431@hans.rg.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/-tPYI0Sxg6R4QVUFphE04T1XBlc>
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: Mon, 13 Jan 2020 15:37:51 -0000

On Tue, Dec 31, 2019 at 07:27:17PM +0000, Lucy Lynch wrote:
> 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.

Indeed. With the new unique value propositions of new applications
like mobile phones and video streaming, the network layer quality and
availability acceptable to users deteriorated quite a bit over pre-IP
solutions.

There was a lot of growth of more network service reliability/quality
demanding applications, but it all happened in vertical industries and
mostly private networks and is IMHO still heavily discriminated against
by the way the IETF operates.

The IETF only has "Internet best (lousy) effort" as the gold standard: Every
new standard is forced to argue how it would behave well if
unintentionally leaking onto the BE Internet, no new standard is harrassed
to support better quality/reliability network layer services (IntServ,
DiffServ, DetNet, etc. pp). 

To me, this is really like asking new transportation standards to explain how
they are compatible with horse manure because horses are still the
golden standard for transportation.  So we continuously reinforce this historic
lowest common denominator and do not encourage really systematically 
the value proposition of better quality/resilience network infrastructures.

Toerless