Re: [Int-area] Where/How is the features innovation happening?

Luigi Iannone <ggx@gigix.net> Tue, 18 January 2022 11:27 UTC

Return-Path: <ggx@gigix.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64B23A08C0 for <int-area@ietfa.amsl.com>; Tue, 18 Jan 2022 03:27:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_PASS=-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=gigix-net.20210112.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 RQoC1JkQ6DlO for <int-area@ietfa.amsl.com>; Tue, 18 Jan 2022 03:27:36 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 08B0F3A08B9 for <Int-area@ietf.org>; Tue, 18 Jan 2022 03:27:35 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id j5-20020a05600c1c0500b0034d2e956aadso3915791wms.4 for <Int-area@ietf.org>; Tue, 18 Jan 2022 03:27:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20210112.gappssmtp.com; s=20210112; h=from:message-id:mime-version:date:subject:in-reply-to:to:references; bh=Zjzq97mJvxt6LYCZbN+cBd/PONNqcxZNZEqqsF2FYyo=; b=6fBIzNW5xlar2Zt311pLgqiBpK9VbP8AfAHYTAHPrIiiczEvstr7Si3NcajqrAXvDF vJgFB6GqpN34B7B2F8liA3KuxjzVzMmCOChxJUokys2rjWx9Of9hyHBJp948nefSn8v5 xX3wtOg/4iH7PvRSfWIDHPnt7la98ce2D4W/XCazDnd3Ce0ckTUdJHd93S6egAYAiepD KkHxyzOltPCeWrh6WhAgUFQY8cfzMXunyiHSiX+q1YfwHSBli23xyUPo3mIw8Z7LOVFM QggT/myT0PDzkYP8I6HWKOE1E0uS4tNOWKWmCOn10KZEdRBoZ3HO3RQe4mpYXGEKfpFE hyMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:date:subject :in-reply-to:to:references; bh=Zjzq97mJvxt6LYCZbN+cBd/PONNqcxZNZEqqsF2FYyo=; b=D/wnQcWsB8EyN4hJLkwmtJ1g+AQaYSR1H0cHV+AB+QxVBZJWuO0R1bALC+54y4cNtU 9NEJdo6BX12JhE30W24kFr28bwrAx5+fSENGGnfR/4J1plG/Hsd/P6toDRRA4/RJFjj9 wk817R55ih5yGVVp9THxg/KhiMx686SsNTleeEK7X2UxA+nQD9RBWQrbEgjRoDkALDGT bs8Z4C+t7fiwxHRWxT7FwtCkw6P/GVbTtsWlpde/0YtkROWGChnjFLJRyaLVrljY+mJ1 fti1QzQeXxhNX1zNsi4/kcj3AtKqzv7zIZ79QUV9wervSJvny7KNSuVZVMjPDAx8SkDu mR6Q==
X-Gm-Message-State: AOAM531qyjIjt9X1mSqz4TClwI06CNS4Oq9hAPzmbUDizd9hi2JD3wVb jzWUjKFmzWdZOIkpSx61IW1mc+8HeDbR8Q==
X-Google-Smtp-Source: ABdhPJy/6E1P6oHP+1Q5No+TiNhF20rU2GOpaGEHT2mfBg6ZLgfMlAEjl1XU0PPuUX3sakXjD2ZkAQ==
X-Received: by 2002:a5d:51d2:: with SMTP id n18mr22433086wrv.441.1642505251891; Tue, 18 Jan 2022 03:27:31 -0800 (PST)
Received: from smtpclient.apple ([2a01:e0a:1ec:470:3cbf:9546:158a:7465]) by smtp.gmail.com with ESMTPSA id b2sm10373826wrx.0.2022.01.18.03.27.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Jan 2022 03:27:30 -0800 (PST)
From: Luigi Iannone <ggx@gigix.net>
Message-Id: <346DEA9F-A4DA-49C6-9976-2E9C3C43B65C@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C563219E-4AA0-4BA2-BEC3-4629AB2ED370"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
Date: Tue, 18 Jan 2022 12:27:30 +0100
In-Reply-To: <5FEE2C71-61D3-498B-AF2F-3B8DFC5C428C@gigix.net>
To: Int-area@ietf.org
References: <5FEE2C71-61D3-498B-AF2F-3B8DFC5C428C@gigix.net>
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/wsWJxAyHStfwaWBpNRGFNflQ8R4>
Subject: Re: [Int-area] Where/How is the features innovation happening?
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jan 2022 11:27:41 -0000

Hi All,
 
Thank you all for the fruitful discussion in this thread.
I am trying to summarize a bit the discussion and here is what I see:
 
·         The ”where” is a 2-dimensional space:
o   Horizontal: Internet edge vs core. The criticality, scale, investment on the core of the Internet makes it more difficult to introduce innovation, while at the edges there is more flexibility.  At the edge of the Internet, it easier to introduce innovation for several reasons: Economics, faster ROI because of faster deployment; No need of large scale deployment (and hence less standardization effort);  less stakeholders involved (sometimes just one, see following point).
o   Vertical: at which layer of the protocol stack. The difficulty to innovate varies as well depending at which layer the innovation takes place. One thing is to innovate at application layer where the app developer has large degree of freedom, another is to innovate at network layer, which is more constrained because of its central point in the architecture. Innovation at higher layer sometimes leads to walled gardens (aka limited domains [RFC8799]). Indeed because of the centralization phenomena, an actor offering a certain service may very well develop and deploy a custom technology that does not need to be actually standardized because it is done for its own internal usage.  
 
·         Horizontal vs Vertical Innovation
o   In the public Internet, core innovation at lower layer is harder, often reduced to app-level innovation or building an overlay limited domain (aka a walled garden).
o   At the edges it is easier to  innovate at lower layers (more vertical flexibility) but some form of adaptation is needed if global reachability is wanted.
 
·         How much unique and globally routable an address should be?
o   With the effect of centralization, edges communicate with (rather) local DCs, hence a unique address globally routable is not a requirement anymore. Dino statement looks well summarizing this point: “We may not need globally unique addresses. But I need a unique address for anyone I want to talk to and I don't care what transmission networks my packets traverse.”
 
·         Flexibility in terms of address properties with respect to the intended use
o   Connection between my phone and my smart watch vs connection between my laptop and a forum of sensitive topics. Having multiple addresses with different properties and/or semantics, to be used depending on the purpose of the communication seems desirable.
 
·         Address privacy
o   This topic comes as a relevant question (also related to the previous point). The use of IPv6 temporary addresses brings benefits that are hard to quantify, and at the moment the best solution seems to be NAT-based. Privacy seems important since has been mentioned in the previous thread.
 
Do folks believe that the text above well summarizes the discussion we had?
 
Let me know
 
Ciao
 
L.
> On 16 Dec 2021, at 10:09, Luigi Iannone <ggx@gigix.net> wrote:
> 
> Dear all,
>  
> We have had a very nice discussion in the previous thread about what kind of features we would want from the Internet. 
>  
> We wanted to come back on another interesting point that has been raised during the side meeting held during IETF 112, namely is where the innovation happening? 
> During the discussion in the side meeting, there was a short exchange between Dino, arguing about “decentralization”, and Michael stating that we are “rebuilding the edges”; the importance of the role of overlays was also briefly mentioned.
>  
> This is not a simple question, and may lead to an architectural argument, in line with Dirk K.’s viewpoint that only such architecture discussion may lead to possible changes to addressing, but also something that emerged in the previous thread. However, let’s at least start from the addressing perspective.
> Rebuilding the edges and utilizing decentralization may point to some approach to addressing that is not governed by a common addressing scheme.
> For instance, could we instead see a diversity of limited domain specific addressing schemes with most effort in ‘addressing’ being placed into the context translation that will need to inevitably happen? Or shall we instead follow the current path that forces the same context (IP semantics) to all participating edges (which goes counter the ‘rebuilding the edges’ comment)?
>  
> Hence the question we would like to discuss with you on: how/where innovation, realizing the features discussed in the previous thread, should happen?
>  
> This can help in strengthening the conclusion of the Problem Statement document (https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/ <https://datatracker.ietf.org/doc/draft-jia-intarea-scenarios-problems-addressing/>), in order to provide input on which way to tackle the problem. 
>  
> Luigi
>  
> (on behalf of the co-authors)
>  
>