Re: [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid

Nishanth Sastry <nishanth.sastry@kcl.ac.uk> Thu, 17 December 2015 21:22 UTC

Return-Path: <nishanth.sastry@kcl.ac.uk>
X-Original-To: stackevo-discuss@ietfa.amsl.com
Delivered-To: stackevo-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840491B30BD; Thu, 17 Dec 2015 13:22:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.191
X-Spam-Level:
X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=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 OoOlSTytWpd1; Thu, 17 Dec 2015 13:22:00 -0800 (PST)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A9E1B30C5; Thu, 17 Dec 2015 13:21:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emc.kcl.ac.uk; s=selector1-kcl-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+DWgUDalq/dDTjBO9Tgfb7fHLlP1DrPKMrPJyEDro64=; b=Zb4Pg0DZDPnfjeYhcLydFypTboWnBEUazJYLlwf6cfZecwq1BHrmMuV2GOgnzcUROWnDwiIZ35CTbtQckKue3Mpuv0rd3gQ08xMNN30/xv00WlaDANPt+ohqicYZo11ctHzS8OkemDeH+ZQOlf76t9tHJvm3cmoYB7WRQvFf5sE=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=nishanth.sastry@kcl.ac.uk;
Received: from [192.168.0.7] (82.1.229.138) by HE1PR03MB1228.eurprd03.prod.outlook.com (10.163.174.154) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 21:21:35 +0000
From: Nishanth Sastry <nishanth.sastry@kcl.ac.uk>
To: Linda Dunbar <linda.dunbar@huawei.com>
Date: Thu, 17 Dec 2015 21:21:32 +0000
Message-ID: <87EE2724-55C3-4BC5-8A43-C2BC15569E5C@kcl.ac.uk>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm>
References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <CAEeTej+pHehyX7+qteogQcAkCcJKYhZoQKStuXGmAzWRj1_rXQ@mail.gmail.com> <F8355406-91C7-4B96-995C-1AD9D7997DC1@kcl.ac.uk> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.3r5187)
X-Originating-IP: [82.1.229.138]
X-ClientProxiedBy: DB5PR03CA0056.eurprd03.prod.outlook.com (25.164.34.24) To HE1PR03MB1228.eurprd03.prod.outlook.com (25.163.174.154)
X-Microsoft-Exchange-Diagnostics: 1; HE1PR03MB1228; 2:QfrzSR+RZvViTOMFRrZrQ+wEsUNm22GDEFGP0bRhABd8MDmFYR5SkC9+TDaMLVe0VZD+ON/MuwyD09MEkvh3+NGxoAZVzZd+AW6RmfjvmpuMEfTp1wf9xSWGRFODcomaPXDD3uOkAMMDJ/ctq5SPCQ==; 3:11oC3oaJapw15MNERlK7eH0xEs6g3wrFz076iSDgFBHjbURicCwBETvHCLDmy3l51CcLyDK8qBWeoLaJlnwCwG32aRAco0Cvr1SU5WqaDVfBKULpJCqrmeBIYO+QoD/a; 25:xr1yzwkf4wKEAMYUyZMwy9Jg/jqwA3gBf2WPpMKCOB7u6s6LRlud8SX15voVaa2RXm7PsABW74AzIJJnKKZ3lQTW/0wz4x/sgpQHxW49jHiQNMcohFUeV6/l529iGziuBR+ECAkYLH6UYa2NqKDyMb34ICCngzeQNCuJnATnNlKQMdlNfnVv6IpPGCdiC7/d11XzO/rkkKAbk8t+S8CmyTs6gd+K97QXBWQ24gxTsgPHjJQTFWwcB656n2hkv3c+BEhXBtIX8AqyfsnoVJ9aRQ==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR03MB1228;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR03MB1228; 20:vBd6gWKRRL7XdWh6XvxnX8STDF8urqY8PE1GCOOCHxTfmkfEswKay/oshwv7//hAX8FpaO2eS8RQc39IjGzwFm5zyXJ57zZJBveDLzy7dItK/k9R5+DWLW/FmdAMqJ/ODz3nAOGDpkeApbSI8UkmUUdu0B+oFta07bJ92peLfrXx0vKWa/+J8Xv1RX5I0Q0TZmuyOGMfbrjjLWX76N3vuJfLEYrZRU3FuNatSEgwqRA0fEO0ZAtbpQekRRl7klAa7wtneM1/IgwS7T23QtsjmRYgjZsJ9rGsZMxU2nQE16Fjk4U77oxceIXPHWbikeJstzLnT/icJBbroDawRudR9CppuX8UwlH65+rosmnMmKAAwdIVrWqOdX3d2yZdt6EZm0A1HTJ7Cfgs6ggxWOd6A94nzAT4YBbkUl6rCPFLC9EYok6VYn1X9ad0fYgdC9KnxG2gs3LWVNFWsRG1RPVIJ0/RvSrL7nWBr3KKvkFA/N1YqAHT1jQlPDtv845EZ4oe; 4:j+PnfSst/fI4lmMzVoC2COpdZ5JAItPcByDyIPxJaJqeciQwCqIxq5X7nXSWGjWjIUl2yQearslV6O9rQxCj440zMCUia6PClBxv7Eu5JlGLcHF+xIXPwP3CNYLivG6KBeRMxG1MpQHXj8UEMpApEzANeWEyjWw/1N9G/k4VFL4Q/6TibNo49h1OZNUvDU7dUzMP9k75HjETSuhIeXuzhA6alMvz6yd3I7khZs/H+87E/0aKaSTLS9FYZGRsqVl0Xs8prAEsWZUxLTlAsYqVgjxMHu8XyPoFwUEmeAiWwMP5ZdJtg2s1SF6/ZBmXkGlXhFLZEz5VskFSt16Dm+IE1X0z4dXadoPtUVCzihmF+rXceVoyMrfKrM5chbELYQxt
X-Microsoft-Antispam-PRVS: <HE1PR03MB122811E44CCB1A1EDE7EF4C9BDE00@HE1PR03MB1228.eurprd03.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR03MB1228; BCL:0; PCL:0; RULEID:; SRVR:HE1PR03MB1228;
X-Forefront-PRVS: 07935ACF08
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(209900001)(24454002)(13464003)(377454003)(164054003)(199003)(189002)(42186005)(93886004)(117156001)(81156007)(5001960100002)(50466002)(82746002)(74826001)(101416001)(83716003)(50226001)(110136002)(23676002)(97736004)(105586002)(189998001)(106356001)(33656002)(66066001)(86362001)(15975445007)(15395725005)(19580405001)(77096005)(19580395003)(16601075003)(40100003)(5008740100001)(87976001)(36756003)(15198665003)(76176999)(2950100001)(1096002)(122386002)(74482002)(586003)(3846002)(1720100001)(92566002)(47776003)(50986999)(6116002)(5004730100002)(493534005)(104396002)(19477635001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR03MB1228; H:[192.168.0.7]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: kcl.ac.uk does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjAzTUIxMjI4OzIzOjhtUmRjSW1DR3ZBbzlxOEdybFRWM2V4UHVU?= =?utf-8?B?aE1RbWhqK1BpZm5Rb3RLbEtOMHJtclFZQ0ExZmtRNE1vT09VRVdjNlhjVXM3?= =?utf-8?B?c3RNOW8yMStZMVp6alRtS1YvQktrTHlscXJGclQ4aVpYeVpKL1lkRW56eEd2?= =?utf-8?B?UnpXR2x0alE4TWV3djMrMXB5ekxYVzlIZlR6T3MvbjVqWW8ydThBUmlodU9M?= =?utf-8?B?TVZVVFdiY1p6VnBrK1NDRGg2WFNrSC8wc2xhTGtkcjI3OFFpanBUeXp4ZDJQ?= =?utf-8?B?MUwyUllJeHF4WGMvem9LczRTQjNPS3dZREZZVHdaemZDWmJsb0JlV0NYbDhu?= =?utf-8?B?YVF1Q2RBRnFXUlo5TmlrenlxNW1LS2tjaGljVjVGV0prd3o1NXZsbzVTMnZa?= =?utf-8?B?RFNnYnFpYWFMVzN4RkRzemdFWCs5Tll0U29FQVZqUEhOMW55YmlMd1pnOHBP?= =?utf-8?B?dTBKcjR1SGZackdmNUdsZHVwZk16QVBIeWNweUZQME9uNHFGSzBaMjFkRU1U?= =?utf-8?B?Q0tMQjd5czkyNmJqTUN2Sm5WWDBvWVJyRVNieWM3Zzc2YUsycVlnbE9TOW8r?= =?utf-8?B?T1kvZXVzUmw4a25NbHIveHRoQTVsNHhoUWNDcDFFQnlDZTljMVVDcERTTU5m?= =?utf-8?B?ekJwMUZqUUpUNGdScWtkcGF0VDgxSDR0dG9KL0FhTTJmOGhZckJ1MEUxV2F5?= =?utf-8?B?bXRkKzFTVmtTLzY2NUhyRENYR2ZhY3VOM3h2YWtkY241UVZGRUpCZ3NGa3I4?= =?utf-8?B?cmtmaTcvMzNxR2xIL0hiOW9TcmpnWmZDenFFVndwUHFHRjdTd2ZrM2prSTJ5?= =?utf-8?B?RCtlVHBHNW00bTlZNWV2QUxtekJScGxhV1RuaDVyV3NBWHFwT3doL3NDdGNI?= =?utf-8?B?TUJaZThXdXcrbUMzU25qSmJiUWxxWE9TS1BacGNSeUcvcENvK0VmcDNaOHBV?= =?utf-8?B?SmdtZ0ZNZGcwcnRkQVhGTEw3SkZrS1FkMjdmcVZhbHJxRW5YVm9tR1NGWUlI?= =?utf-8?B?czIxdldWTlMvREdXVVdDOWxLMlNvbmdLMVp1R0N6dEplZkFRR05vVFBCdjNB?= =?utf-8?B?VUV6TE1EckFBS21vbHNjZ09LL1l4ZGdNMUZPeTUraTl6YmVWc01WQWVsZkx6?= =?utf-8?B?M0V1cTQ4NHUwOC9EOHUrN01uL2l5emtzbHF4Y05zUURnN0FYNVdDYTdEdzVI?= =?utf-8?B?Y0hwaGhFemRKdkNQazdmMGlGY01rVk1nQm01UityVmE1VmJ0NGlhQk53aTNu?= =?utf-8?B?MWp3SkxjOW5POEV3WktsODZpRm9XV2wyd1ZnUjh6WUlHWFFTS2VnanJHZmZw?= =?utf-8?B?L0RqcHpWSk5rLzJYd1hucjh2OHpzVG5NbWpqdkdIdHViRUpNK1ZYTVdtR3pl?= =?utf-8?B?TXd1bWZrd0EvNG5oUXFsWExHSGdkaG9zbGUvZEQrQ3Y1dXJXeHFzQjZuWXJJ?= =?utf-8?B?d1Izc2N1dHAzYXE2TjN0dFpOdjJhclVCbHoxWFc1U2RPTXZQMFY4NXVaeG5o?= =?utf-8?B?dGhBL0xNZE1VM2NlVjZUaVZoa005bzFaZWtJeDVqdHlYWHViTFd1L2pUMXND?= =?utf-8?B?ZE5rZWRDZGJtWFVWYm5hOWNPU2U5Y0ZjSWVBdHVTenZ1ek1CeFFPWEpFQXhp?= =?utf-8?B?SndsMG9UeUpqU0NpNzlKQ29jN2FwU0I3VXMxS3ZYYVh6Q1haRWY2NTJNR0xx?= =?utf-8?B?TkJQNktEcnoxZ0xUekNPVTdmVG95cW9JRGlHcEZXZXlRdWZQQUUzWUMzMGVn?= =?utf-8?B?cTNoT3p3NE1xamJTamhxL2VyZDNJTXN3QzhKVmg5UTJnMnI0WWxuMmNDc1hm?= =?utf-8?B?cE0ybE1nNDJkSjFPNHB5RHFkNWE0ZWVrbkNFQzBCU1JSNE5ZQ0owSFkrM1FQ?= =?utf-8?B?ckhSK2RQQkhBb29VbzZWcUEwdjJCbE84QSt3dnpZbmE2N0hsejdqclkyZU1S?= =?utf-8?B?cWsxMFA0ZFlueERIWUc1SFQvcUZpMGhXNm5BclhYVzhlalBNc0VBcWFqZjRI?= =?utf-8?Q?TCd52Y?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR03MB1228; 5:O4FVcYCow5WiUc+M9h+oICCU6qeyQx+V+mn3S/ooWOob8ne26/FDxqVBzG7vSPxqnTMmQHUi4gDbgmCGSLK5AezS7jJPs16i/KE8Xp9TE4RvW0dvvjRf09Chc/ijORGndTp64v5azJGR0Lm3lDGABg==; 24:GoEsbtaPlVXo7fnO1aTlTqTlQJeFLqsbcR7UXGiGa7lX0ieHL30epSj8Jq6nYNy1mNpE8z5sPexKCFCLKPNeQoSLn8JMs1XO/WS2oQ6pd4E=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: kcl.ac.uk
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2015 21:21:35.8857 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR03MB1228
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo-discuss/JiaO2URnMI7Ha2U5hv0YAZIrNHE>
Cc: "icnrg@irtf.org" <icnrg@irtf.org>, gaia <gaia@irtf.org>, "stackevo-discuss@iab.org" <stackevo-discuss@iab.org>, Dirk Kutscher <Dirk.Kutscher@neclab.eu>, Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>, "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" <marnew@iab.org>, "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Subject: Re: [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid
X-BeenThere: stackevo-discuss@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IP Stack Evolution Discussion List <stackevo-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo-discuss/>
List-Post: <mailto:stackevo-discuss@iab.org>
List-Help: <mailto:stackevo-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 21:22:02 -0000

Agree. If we were to do flow level isolation, I would imagine it would 
be a realised as a trusted application requesting new per-flow slices on 
a given operator's network, or, if we go down the bromium route, the 
network itself spinning up a new "micro-slice" for every new flow rather 
than the user or UE obtaining slices on demand.

[However, the academic in me wants to note that user identities are much 
stronger in cellular networks than in the fixed-line Internet, so it is 
not impossible to have a model where the operators networks are simply a 
platform for creating new slices and hosting application-specific VMs, 
and the user creates and is charged per slice (one could have S/M/L/XL 
slices which are differently priced). The user (or an app on the user's 
behalf) then decides which flows can interfere with each other, and 
derive stat muxing benefits, and which flows need to be isolated from 
each other in different slices. Different users' slices would by default 
be in different slices, which brings back the "Silos in the Network" 
problem that Dirk talks about in his article. :-)]

nishanth
—
CD-GAIN: http://bit.ly/cd-gain
S4S: http://www.space4sharingstudy.org/
REACH: http://www.eu-india.net

5G Norma: https://5g-ppp.eu/5g-norma
VirtuWind: https://5g-ppp.eu/virtuwind/

On 17 Dec 2015, at 17:49, Linda Dunbar wrote:

> I strongly support the concept of network slicing for Applications or 
> IoT networks.
> But it is not realistic to expect operators networks to take control 
> requests from individual users/handsets. There has to be an 
> authenticated application controller that makes requests/commands to 
> the sliced network.
>
> My two cents.
>
> Linda
>
> -----Original Message-----
> From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On 
> Behalf Of Nishanth Sastry
> Sent: Thursday, December 17, 2015 6:43 AM
> To: Jon Crowcroft
> Cc: icnrg@irtf.org; gaia; stackevo-discuss@iab.org; Dirk Kutscher; 
> marnew@iab.org; 5gangip@ietf.org; dtn-interest@irtf.org
> Subject: Re: [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid
>
> E2E security in 5G can be addressed through network slicing, another 
> concept which seems to be included in many 5G proposals. If each 
> application has its own slice, it can screw up but wont be able to 
> affect other applications. Within each slice, E2E security can be 
> enforced in an application specific manner. Even better would be if we 
> can make each flow be its own slice. This may seem to be overly 
> heavyweight, but is along the lines of what Bromium  is trying to do 
> for desktops, isolating processes and data from each other using
> "microvisors": http://www.bromium.com/why-bromium/how-we-do-it.html We 
> just need to do it for networks :)
>
> nishanth
> —
> CD-GAIN: http://bit.ly/cd-gain
> S4S: http://www.space4sharingstudy.org/
> REACH: http://www.eu-india.net
>
> 5G Norma: https://5g-ppp.eu/5g-norma
> VirtuWind: https://5g-ppp.eu/virtuwind/
>
> On 17 Dec 2015, at 7:56, Jon Crowcroft wrote:
>
>> Great article...one thing about the 4g..5g evolution is increasing
>> cooperation in forwarding and relaying signal, bits, packets (shared
>> cell
>> tower/base station/antennae across provider). So direct,mesh,adhoc
>> stop
>> just being edge notions, but are all first class part of the
>> architecture
>> ("don't fear the edge"). There is huge tension between this trend, 
>> and
>> e2e
>> security....I have not seen anyone address how to resolve that
>> tension...
>> On 16 Dec 2015 6:42 pm, "Dirk Kutscher" <Dirk.Kutscher@neclab.eu>
>> wrote:
>>
>>> [apologies for cross-posting]
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> I have written up a few thoughts on current discussions around 5G 
>>> and
>>> network evolution. I might publish this as paper later, but wanted 
>>> to
>>> get
>>> it out early and ask for comments – so would be grateful for any
>>> feedback.
>>> It’s not very polished and slightly long, but hopefully
>>> understandable
>>> enough. Take it as a “position paper” for now.
>>>
>>>
>>>
>>> Abstract:
>>>
>>> Current 5G network discussion are often focusing on providing more
>>> comprehensive and integrated orchestration and management functions
>>> in
>>> order to improve “end-to-end” managebility and programmability,
>>> derived
>>> from NGMN and similar requirements. While these are important
>>> challenges,
>>> this memo takes the perspective that in order to arrive at a more
>>> powerful
>>> network, it is important to understand the pain points and the
>>> reasons for
>>> certain design choices of today’s networks. Understanding the
>>> drivers for
>>> traffic management systems, middleboxes, CDNs and other
>>> application-layer
>>> overlays should be taken as a basis for analyzing 5G uses cases and
>>> their
>>> requirements. In this memo, I am making the point that many of
>>> today’s
>>> business needs and the ambitious 5G use cases do call for a more
>>> powerful
>>> data forwarding plane, taking ICN as an example. Features of such a
>>> forwarding plane would include better support for heterogeneous
>>> networks
>>> (access networks and whole network deployments), multi-path
>>> communication,
>>> in-network storage and implementation of operator policies. This
>>> would help
>>> to avoid overlay silos and finally simplify network management.
>>>
>>>
>>>
>>> http://dirk-kutscher.info/posts/5g-its-the-network-stupid/
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Dirk
>>>
>>>
>>>
>>> _______________________________________________
>>> gaia mailing list
>>> gaia@irtf.org
>>> https://www.irtf.org/mailman/listinfo/gaia
>>>
>>>
>> _______________________________________________
>> gaia mailing list
>> gaia@irtf.org
>> https://www.irtf.org/mailman/listinfo/gaia
>
> _______________________________________________
> Stackevo-discuss mailing list
> Stackevo-discuss@iab.org
> https://www.iab.org/mailman/listinfo/stackevo-discuss