Re: [arch-d] A Public Option for the Core

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 16 August 2020 00:03 UTC

Return-Path: <brian.e.carpenter@gmail.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 DB7683A0B37 for <architecture-discuss@ietfa.amsl.com>; Sat, 15 Aug 2020 17:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, 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=gmail.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 6gPFUrJMRbkD for <architecture-discuss@ietfa.amsl.com>; Sat, 15 Aug 2020 17:03:01 -0700 (PDT)
Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 3B1B13A0B36 for <architecture-discuss@ietf.org>; Sat, 15 Aug 2020 17:03:01 -0700 (PDT)
Received: by mail-pl1-x643.google.com with SMTP id t11so5757532plr.5 for <architecture-discuss@ietf.org>; Sat, 15 Aug 2020 17:03:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QCULlA/6eMkUFuaC9YIQd6HgHi5mh8vCNhV/BWeN83w=; b=sa2cJwtUBk5Hxa+X5GUOm1iOittX2N5rj3b/6DoJsOgYtyTH/AUYy/CVmNN/swufYg cSphS8mjmESEEVnpSIkIPIJLgJTda7dB64qZ6dCMfrV4khrHEe6OKEvc5u81Iy5PkRI7 2YfH9NL13NOCLiSCQL4oMEcFBJzdBX0G1+wk3hOXzXDcw1d9zUffE5WK974NRx4sImni fyhrQXY7CAkYyA154rijO7PVjsMEnrqY5Kt/8lwW5LvIGYWdS+OmcRNmezYbukQPAl8h d87+KBHIdhtVGpf31FlhzcgF4KEz6DFayFcYYXkViIOMGqBwrJ07arNDq/ympb7IQYRx 2Dag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QCULlA/6eMkUFuaC9YIQd6HgHi5mh8vCNhV/BWeN83w=; b=rzXW3gcnJBbZAVBKBxv1ghyy6c+a73NIrSHB1vIQq58gNblMeWNyUc5F+rdSQsPRN4 IgoLZ22n8LhWr6upsWpy0d5fQ4roBUe/K66xPXCr2L/vnSdqVt0/Z6UO9sR5Zw28Sl48 A7t9E8fwitKMTImPOApfIFZyaWcro02+KtLOZugS8xZsupTT757OYBQQABa4nIJi/BUn 5oEimGVVD21Yi0Zg/wZpFinYy43BWVB5M10fgGZMD1tcFnYRYWtZoullm7ZhBWx7oWX8 roEasIeLzdxHe3wakYfnHlJ/fpy0/ZjNvxZ0xRJiS9nvsMlhLyj46UcW/FJURbMqWRxK 1dSw==
X-Gm-Message-State: AOAM533K4h4+AYsZwuy8LdTDRaMN5K0c7XNjncicFEarP6/XZWbGIvBg rRJDOPoG4iJdkur9uONeZh/+QGzFir8/ew==
X-Google-Smtp-Source: ABdhPJxMdZYJ6h9BfqNGqjs/ws2fx0b9BDBu+n0EcJD3vdSPXOochPLF7YNB4Xb/7VMj/CCEP9hvGg==
X-Received: by 2002:a17:90a:21c6:: with SMTP id q64mr7258610pjc.119.1597536180267; Sat, 15 Aug 2020 17:03:00 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id l63sm11771867pgl.24.2020.08.15.17.02.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Aug 2020 17:02:59 -0700 (PDT)
To: Scott Shenker <shenker@icsi.berkeley.edu>
Cc: lars@eggert.org, architecture-discuss@ietf.org
References: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> <c80bdd1e-eeac-534d-7d2e-e1b04c9144c8@gmail.com> <47EBBED2-2FE9-42B3-BD37-C81DA84A42F8@icsi.berkeley.edu>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <101d7750-5744-5607-663f-4e2ad0f4ff6e@gmail.com>
Date: Sun, 16 Aug 2020 12:02:56 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <47EBBED2-2FE9-42B3-BD37-C81DA84A42F8@icsi.berkeley.edu>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/zz9npAOp9aAiSQLDC97KTapS86Y>
Subject: Re: [arch-d] A Public Option for the Core
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, 16 Aug 2020 00:03:03 -0000

On 13-Aug-20 01:19, Scott Shenker wrote:
> 
> 
>> On Aug 11, 2020, at 3:53 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>> (Bcc to the IETF list and Cc to the architecture-discuss list)
>>
>> Thanks for circulating this.
>>
>> On 12-Aug-20 06:50, Lars Eggert wrote:
>>> Hi,
>>>
>>> Scott Shenker et al. just presented a pretty thought-provoking "public option" for the Internet's core backbone at SIGCOMM: https://dl.acm.org/doi/abs/10.1145/3387514.3405875
>>
>> Hmm.
>>
>> "The technical Internet community has long embraced the notion
>> that the Internet should be application-neutral; that notion later
>> became known as network neutrality (a term coined in [57])."
>>
>> I dispute that assertion. "Network neutrality" is a slippery term,
>> but certainly there is antipathy between some interpretations of it
>> and RFC2474 and other QoS technologies.
> 
> We did not mean to imply that the two are notions are identical, and indeed we discuss the no-QoS interpretation of network neutrality later in the paper. However, I think it is undeniable that conceptually the notion of network neutrality is the descendant of application-neutrality, which was the intent of this sentence. I apologize if our writing was unclear.

I'd go a bit further. We don't want application-type neutrality, because (e.g.) video streams require different service characteristics from (e.g.) software update distribution. What we want is application-service-provider neutrality, so that streaming from CarpenterTube gets the same service as streaming from ShenkerTube. I know that the authors know this, but the policy-level debates have often been unclear on this point.

>>
>> "We choose instead to initially create the POC’s backbone network out
>> of a set of leased lines, and use the interconnections to one or more
>> ISPs as a fallback if the POC’s backbone does not have sufficient
>> connectivity."
>>
>> That sounds like a fairly accurate description of the Internet in
>> about 1995, when ISPs had emerged but the de facto backbone was still
>> largely non-profit and/or settlement-free. And note that non-profit
>> transit networks existed then, and actively migrated to a for-profit
>> model after about 1998. See https://en.wikipedia.org/wiki/EBONE for
>> an example.
>>
>> So I think history would likely repeat itself if this proposal was
>> adopted.
> 
> The world of today is very different from what it was in 1995, particularly in terms of the market forces at work. We discuss our reasoning for why our proposal might become a reality later in the paper (in a section called “Are We Crazy?”), and I would be interested in your reaction. Do you think the market forces we identify might lead to a different result now?

As you say: "Our alternative is to cleanly separate transit and last-mile-delivery" and indeed that would be a good thing. I appreciate this comment: "If more and more LMPs find the POC attractive (and the success of
IXPs in Europe suggest that this is not farfetched)...". As it happens it was Olivier Martin in my group at CERN who set up the CERN neutral IXP in [thinks hard] late 1995, and it's still going strong today (https://cixp.net/about-cixp). In the world of 1995/96, ISPs jumped onto to the CIXP precisely because it was non-profit and neutral.

My question is whether today's LMPs are able to take independent decisions to migrate to the POC. The difference from 1995 is surely that most LMPs are not independent so cannot take such a decision.

Incidentally I would expect a real deployment of the POC to start by peering with as many of the non-profit IXPs as possible. That would create an instant flash mob of POC users. Successful peering is its own best advertisement.
 
> More generally, as an academic working on issues related to the Internet, I view it as my mission to identify designs and paradigms that would make for a better Internet, and to explore whether there are plausible paths to such eventualities. We recognize that our proposed change is a long-shot. In fact, almost all attempts to effect large-scale changes in the Internet (whether its design or its structure) are likely to fail.   My responsibility as a researcher is to not let that stop me, and my mission as a member of the Internet community is to try to make such changes happen, despite great odds. I hope that people on this list and elsewhere read this paper in that spirit.

Absolutely, and thanks for working on this.

   Brian

> 
> —Scott
> 
> 
>>
>> Maybe it's time to update https://tools.ietf.org/html/draft-carpenter-metrics
>> Reactions to that draft from the then major transit ISPs were interestingly
>> negative.
>>
>>   Brian
>>
>>>
>>> If you scroll down (or go to https://dl.acm.org/doi/abs/10.1145/3387514.3405875#sec-supp), his recorded talk video gives a high-level overview.
>>>
>>> (PDF and video *should* be open access and work for me, but you never know with the ACM...)
>>>
>>> Lars
>>>
>>
>> _______________________________________________
>> Architecture-discuss mailing list
>> Architecture-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
> 
> .
>