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

AshwoodsmithPeter <> Fri, 18 December 2015 14:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 13A091B3650; Fri, 18 Dec 2015 06:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k4AL4LbIGw0z; Fri, 18 Dec 2015 06:16:15 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 381251B365B; Fri, 18 Dec 2015 06:16:12 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DBD83736; Fri, 18 Dec 2015 22:15:30 +0800 (CST)
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Fri, 18 Dec 2015 22:15:18 +0800
From: AshwoodsmithPeter <>
To: Linda Dunbar <>, Nishanth Sastry <>, Jon Crowcroft <>
Thread-Topic: [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid
Thread-Index: AQHROW5WZcE4Jya+TkWrglMNHXDB+p7QyYGA
Date: Fri, 18 Dec 2015 14:15:17 +0000
Message-ID: <>
References: <> <> <> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56741504.018C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 648c0d88d80ad11c6b3aa3548ac1e53e
Archived-At: <>
X-Mailman-Approved-At: Fri, 18 Dec 2015 08:14:39 -0800
Cc: "" <>, gaia <>, "" <>, Dirk Kutscher <>, "" <>, "" <>, "" <>
Subject: Re: [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IP Stack Evolution Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Dec 2015 14:16:18 -0000

I tend to agree. A slice per user, except in exceptional cases would seem unlikely. Since a slice requires multiple resources be allocated end to end the concept most likely will work best for a set of users that share a common QOS/QOE/Admin requirement.

Essentially QOS/QOE within a slice will still have to be addressed with the tools we already have.


-----Original Message-----
From: 5gangip [] On Behalf Of Linda Dunbar
Sent: Thursday, December 17, 2015 12:49 PM
To: Nishanth Sastry; Jon Crowcroft
Cc:; gaia;; Dirk Kutscher;;;
Subject: Re: [5gangip] [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid

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. 


-----Original Message-----
From: Stackevo-discuss [] On Behalf Of Nishanth Sastry
Sent: Thursday, December 17, 2015 6:43 AM
To: Jon Crowcroft
Cc:; gaia;; Dirk Kutscher;;;
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": We just need to do it for networks :)


5G Norma:

On 17 Dec 2015, at 7:56, Jon Crowcroft wrote:

> Great 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" <>
> 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.
>> Thanks,
>> Dirk
>> _______________________________________________
>> gaia mailing list
> _______________________________________________
> gaia mailing list

Stackevo-discuss mailing list
5gangip mailing list