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

Andrew Campling <andrew.campling@419.consulting> Mon, 17 August 2020 13:55 UTC

Return-Path: <andrew.campling@419.consulting>
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 1B0D03A156C for <architecture-discuss@ietfa.amsl.com>; Mon, 17 Aug 2020 06:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 0T8Ok6Wd3uL2 for <architecture-discuss@ietfa.amsl.com>; Mon, 17 Aug 2020 06:55:25 -0700 (PDT)
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100082.outbound.protection.outlook.com [40.107.10.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86D13A156A for <architecture-discuss@ietf.org>; Mon, 17 Aug 2020 06:55:24 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kpSIH+lGdNfkzV8oUUFrzlDJomMLsHnS5g9JEHov2lZgDcUepyS5X7ou5fQdpTrVivpYHo9MF1S0QOkbgUM9HCnbo8FOMkYrKaTHDC90YIyJW2otPcTRnWarmLlcjfcJyYt5snwrSji0+VIRM4dQSolTnhMAIBXMFiTOJ49ZQlRtQBpS576vZ6h1qBBHrzV1rFS7/xsXErFlenyYlnmhF9u8GD4cCg6L4sc0lc0UfGBvQRvmk1ttC//3wlnn7abFiqQ2aLT6UI8mg7BpUTsWiknD7WM1Y5g8SIqKFyGDhQTyDOTfidnbDSTAALt0pI0SKjwNC5Pc7kr7RTTSr+AYxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u9eJEu6XXXYCe1Qs8xGUh7TWIEZIfcgg7QFuxFjMM0A=; b=bNgvsIoehXB5rtonDgtPSk4TCr0EGxuByXdAa+3xo19TLKUTdrMOYiShc/kNw0Lr5ryjLvXRc+O55mNeempMH/8XtpxsBKs3S+X9UrW54UA3zPmuFYdA+3woQi07Ojy/Z8Vl1heoEK46bDsxMF8bHBG+6KsnFwxQqDq4mU21vbb02HKqw5RNUx/IzVGpdF3d8srtXXz78gA5SFBvRcZ7xpyZlUFKbheId1MEV1wEU4F1WPL7l4SW58SYm8YyziJhnpCoU8U1VygjXJw96BKhef3F61wJIJEOLoApbC0QoOXVU1E/WDRID4VB48fE0JOftJ+qou3tIhyK9otqZ3fzhw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u9eJEu6XXXYCe1Qs8xGUh7TWIEZIfcgg7QFuxFjMM0A=; b=h6PvB53L44c+X3mIF1JQb5nubYhqhtETKm29Ggpj/jie7xfTGwrIZlsWaNikSjMi/tWZcrEFrXl2v+pxvgAlgrsYfIQD2sDl5H2iaUB44yiJwGj+Zxg4X8go91kFBBFFI4uclycJgjgiRJSs9sNi+uzmUavUais35iBGecJqcww=
Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) by LO2P265MB0830.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:6b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Mon, 17 Aug 2020 13:55:14 +0000
Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::91fb:af23:a084:10cf]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::91fb:af23:a084:10cf%7]) with mapi id 15.20.3283.027; Mon, 17 Aug 2020 13:55:14 +0000
From: Andrew Campling <andrew.campling@419.consulting>
To: Toerless Eckert <tte@cs.fau.de>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: Joe Touch <touch@strayalpha.com>, John Day <jeanjour@comcast.net>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Thread-Topic: [arch-d] Fwd: A Public Option for the Core
Thread-Index: AQHWdJmqEQ4JuXcUG0Sv0cTNGUdaaKk8T1QQ
Date: Mon, 17 Aug 2020 13:55:13 +0000
Message-ID: <LO2P265MB057308CC06E712D6B372D4A8C25F0@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <FB381338-A278-45B2-A40B-3A065E3A3ED1@strayalpha.com> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=419.consulting;
x-originating-ip: [2a00:23c4:a499:2e00:a064:d5c5:8b3b:ec1b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 830e7297-a1e8-4a03-0cfa-08d842b52a65
x-ms-traffictypediagnostic: LO2P265MB0830:
x-microsoft-antispam-prvs: <LO2P265MB08305116BD052F6FC8775203C25F0@LO2P265MB0830.GBRP265.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: kFWvJgJ9Qh69eK0mMJoD72oBW6MpT6yz+uGotpsfLBLTsNJlhlFa+NRyah8ZU/CVqQkzz0iu/5IzvhWTaK3j8NLTJQ8UVOXwowK6NmpEadEq7KVCHPwpvB9dE+DDRDW+oKkcSlDjisqizq38D/NKrdPPVa2BEtGpK3NUE8qXf51gEaqfhnGAjgPdilWs3UpCC4IPeO4T49v6cyTIFZ6oTJo7KiHD0UZQh0a/YK2vwL3Mex+zETcL2zpG3NSN63176zlI66u0jSQaJZlOBSEEX9AEIluPKr5ESbKs7UDb7Lc9lHz5cr9sJbJlTFDsO/huIiqZ672KHjMUJ+s7KSET3uW5G2rsPMuodXfutOKwdg137R0RSM0+YCAQusuomxCMsksQmvIbhPjkUqmlfph/H4L+ZPaH/j5lIz7oVV+AQYeo7Ub2RvbkbuWe3ie+yIr+Phc+7tygiNEJxCHHhXpAMw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(39830400003)(396003)(366004)(346002)(376002)(76116006)(6506007)(316002)(4326008)(53546011)(71200400001)(186003)(8676002)(33656002)(966005)(5660300002)(66574015)(54906003)(83380400001)(44832011)(478600001)(8936002)(55016002)(9686003)(2906002)(7696005)(64756008)(66556008)(66476007)(66946007)(110136005)(86362001)(66446008)(52536014)(46492007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: H9pz/rHi3VGZUa09++SDcZWb6N/zG1ukNaINN17wXbswJGXJXOJoYWIJJhnbzxplDVm9hfRcn+5oLEUeXf/OBVAQBiv1M27gWdPfpp8ByZE79FT31YoU4VZI9v0Tk1rFnCZksXWAY+l0lrcggaI+Dg0HGQ/jkqhSGSCMhs3oSQSIAWc86doVNyDRI5SZfJ8vov14XxO6YpOQCG75IJyNYcO8779vaYliBwraN4KfGSWytCVCp7N7a6dQN1tQ9cRMqt/wFFveGb2Er2gGzQHT2MeDIvpVUdJy7tZ5OID8ywE4M1CnTPk84awzz3+Sc3qyMvZWopZH717Dq/FJ5j3QgSZJKkeiv5Z1KNjW1YkbIHBxXPKu7cda+dnmmbZpdNhahZlWEjtx5SR4XEdmAGSnxFP9OvyyshoYsghtK35QevkJFqCCkTIF1c4OsvP0y6ieMnal5Nds/WWMl4FGNQPUW6zRyd1gOecuFaGps8yHOigNpGG8Fu15Bho7Um03GQY6wqinjFiJVfDObPFUyoJDYoXdRW5Vcc/q08ZQqx5sNZuDlKshcwaSb+qLu9xdvRIv9vM97NbAmjFg0Hf28eixyPovQ9WY6asByCfFHaGXOLABpgMnspVCaC74oHgkQ34g0xCWF9ziSOwGh55bkZv4rBO/1dUt9wmR7e5o9s9/rjd3ke1zR7RHarupnb1iYxmybTAgUOVGiTy1Cglz/blJkw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: 419.consulting
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 830e7297-a1e8-4a03-0cfa-08d842b52a65
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 13:55:13.9944 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: aDAcJVzuzhLkrhVyqcoEyVDf7Cn1TM2FYuV5d/Jy19/dSKBHW+KlvrgJH6P8Ll8J2I7MDSHKiqjqIP+ISYJv9PW9Ia3MQpd0oLuMLYYkMeM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0830
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/lreC51oS6uHfEcoLEI6Ikp3xsno>
Subject: Re: [arch-d] Fwd: 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: Mon, 17 Aug 2020 13:55:27 -0000

> On Aug 17, 2020, at 03:46, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> John, Joe, Brian:
> 
> All great discussion points, but i am not sure if JohnD's starting 
> point of "no deductive adaptation of behavior" is really mandatory 
> and/or sufficient for *I* net neutrality. Aka: Do we even have an 
> approved and complete *I* "net neutrality" definition ? If so, where ?

You seem to be assuming that "net neutrality" is always a good thing?  My personal preference is for networks to be transparent in the way that they manage traffic (if at all) so that I can choose my network based on what they do.  A network without, for example, any form of QoS might perform very poorly for at least some applications.  

> Btw, IMHO: Having an application tell the network exactly what it 
> wants from the network is quite a challenging task for applications.
> When i worked with enterprise application developers, they wouldn't 
> even want to bother to understand what differences in service from the 
> network would best help the application.

This point I agree with.  In general, the level of knowledge of networks by applications developers can be very low (and vice versa), they exist in very different worlds.  
 
> Hence we thought of a framework where the application would instead 
> attribute traffic as to what it is, e.g.: application FOO, wihthin FOO 
> floX, e.g.: X = audio/video/...  Aka: Whatever the application developer was 
> able/ willing to tell.
> 
> Then one can have a trusted layer that would map this information to 
> actual network service requirements/advisory information.
> 
> In classical enterprise environments, this trusted mapping layer could 
> typically be a nework device (given how applications in enterprise are 
> subject to a lot of control by the enterprise operator anyhow).
> In typical residential environment, the trusted mapping would likely 
> best be the browser, given how that performs all type of control 
> operations against applications anyhow.

Whilst I believe that I understand your point, I'm not at all convinced that, in residential environments, delegation of trusted mapping to browsers makes a lot of sense.  That seems to present a fine attack service for future exploitation.  No doubt others will have different views though.  


Andrew

-----Original Message-----
From: Toerless Eckert <tte@cs.fau.de> 
Sent: 17 August 2020 08:47
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Joe Touch <touch@strayalpha.com>om>; John Day <jeanjour@comcast.net>et>; architecture-discuss@ietf.org
Subject: Re: [arch-d] Fwd: A Public Option for the Core

John, Joe, Brian:

All great discussion points, but i am not sure if JohnD's starting point of "no deductive adaptation of behavior" is really mandatory and/or sufficient for *I* net neutrality. Aka: Do we even have an approved and complete *I* "net neutrality" definition ? If so, where ?

Btw, IMHO: Having an application tell the network exactly what it wants from the network is quite a challenging task for applications.
When i worked with enterprise application developers, they wouldn't even want to bother to understand what differences in service from the network would best help the application.

Hence we thought of a framework where the application would instead attribute traffic as to what it is, e.g.: application FOO, wihthin FOO floX,
e.g.: X = audio/video/...  Aka: Whatever the application developer was able/ willing to tell.

Then one can have a trusted layer that would map this information to actual network service requirements/advisory information.

In classical enterprise environments, this trusted mapping layer could typically be a nework device (given how applications in enterprise are subject to a lot of control by the enterprise operator anyhow).
In typical residential environment, the trusted mapping would likely best be the browser, given how that performs all type of control operations against applications anyhow.

Cheers
    Toerless

On Mon, Aug 17, 2020 at 08:24:06AM +1200, Brian E Carpenter wrote:
> On 17-Aug-20 03:01, Joe Touch wrote:
> > And the second is that service level implies connection. It only requires the network understands a label *I* control, rather than trying to infer one from the packet contents.
> 
> However, it does need some kind of flow state (whether flows are individual or aggregated) in the forwarding queues. Not that this is a new argument; we had it in the diffserv WG many years ago and it continues to this day in TSVWG.
> 
> I don't think this really affects the basic arguments for a "public core". It just indicates that transit networks don't need to be strictly best effort and stateless in order to be neutral.
> 
>    Brian
>  
> > 
> > Joe
> > 
> >> On Aug 16, 2020, at 3:19 AM, John Day <jeanjour@comcast.net> wrote:
> >>
> >> ???
> >>
> >>> Begin forwarded message:
> >>>
> >>> *From: *John Day <jeanjour@comcast.net 
> >>> <mailto:jeanjour@comcast.net>>
> >>> *Subject: **Re: [arch-d] A Public Option for the Core*
> >>> *Date: *August 16, 2020 at 06:18:04 EDT
> >>> *To: *John Grant <j@ninetiles.com <mailto:j@ninetiles.com>>
> >>>
> >>> No, that is not true.  Your first mistake is that there is a control plane.
> >>>
> >>> John
> >>>
> >>>> On Aug 16, 2020, at 06:02, John Grant <j@ninetiles.com <mailto:j@ninetiles.com>> wrote:
> >>>>
> >>>> On 16/08/2020 02:48, Joseph Touch wrote:
> >>>>> *I* want apps to be able to get different service from the network and to pay differently for them if needed, but *never* to have the network infer or enforce that mapping.
> >>>> Of course, if you're going to do that -- have the application negotiate a particular kind of service rather than have the network "inspect" the packets and guess what service is needed -- you need a control plane protocol (let's call it "signalling") to do the negotiation, and you no longer have the connectionless/stateless paradigm on which IP is founded.
> >>>>
> >>>> --
> >>>> John Grant
> >>>> Nine Tiles, Cambridge, England
> >>>> +44 1223 862599 and +44 1223 511455
> >>>> http://www.ninetiles.com
> >>>>
> >>>> _______________________________________________
> >>>> 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

--
---
tte@cs.fau.de