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

Dirk Kutscher <Dirk.Kutscher@neclab.eu> Thu, 17 December 2015 09:53 UTC

Return-Path: <Dirk.Kutscher@neclab.eu>
X-Original-To: gaia@ietfa.amsl.com
Delivered-To: gaia@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925B51A877F; Thu, 17 Dec 2015 01:53:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 jNChC5ZI-8AK; Thu, 17 Dec 2015 01:53:42 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA151A8758; Thu, 17 Dec 2015 01:53:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7799410B517; Thu, 17 Dec 2015 10:44:26 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzEx-8BNfu2i; Thu, 17 Dec 2015 10:44:26 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 543B610B4BB; Thu, 17 Dec 2015 10:44:12 +0100 (CET)
Received: from HYDRA.office.hd ([169.254.4.101]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Thu, 17 Dec 2015 10:43:51 +0100
From: Dirk Kutscher <Dirk.Kutscher@neclab.eu>
To: Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
Thread-Topic: [gaia] 5G: It's the Network, Stupid
Thread-Index: AdE4MC4YYpSof3RGRdK/YSjH5J56uAAZ/GyAAAWAjeA=
Date: Thu, 17 Dec 2015 09:43:50 +0000
Message-ID: <82AB329A76E2484D934BBCA77E9F5249A683460E@Hydra.office.hd>
References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <CAEeTej+pHehyX7+qteogQcAkCcJKYhZoQKStuXGmAzWRj1_rXQ@mail.gmail.com>
In-Reply-To: <CAEeTej+pHehyX7+qteogQcAkCcJKYhZoQKStuXGmAzWRj1_rXQ@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.2.102]
Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F5249A683460EHydraofficehd_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gaia/M9Ms5E1mcM_DuJ4aCh3x8E_sb9k>
Cc: "icnrg@irtf.org" <icnrg@irtf.org>, gaia <gaia@irtf.org>, "stackevo-discuss@iab.org" <stackevo-discuss@iab.org>, "marnew@iab.org" <marnew@iab.org>, "5gangip@ietf.org" <5gangip@ietf.org>, "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Subject: Re: [gaia] 5G: It's the Network, Stupid
X-BeenThere: gaia@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Global Access to the Internet for All <gaia.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/gaia>, <mailto:gaia-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gaia/>
List-Post: <mailto:gaia@irtf.org>
List-Help: <mailto:gaia-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/gaia>, <mailto:gaia-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 09:53:43 -0000

Yes, good point. That was actually a notion I had in mind, too, but forgot to mention: Don’t have assumptions in the architecture on where the network ends.

IoT is illustrating the need for that to some extent already.

Regarding security, unless we want to introduce “trusted middleboxes”, object encryption and authentication seems to be the way. Of course there are other challenges for that, too – key management for example.

--
Dirk

From: crowcroft@gmail.com [mailto:crowcroft@gmail.com] On Behalf Of Jon Crowcroft
Sent: Donnerstag, 17. Dezember 2015 08:57
To: Dirk Kutscher
Cc: dtn-interest@irtf.org; stackevo-discuss@iab.org; icnrg@irtf.org; gaia; marnew@iab.org; 5gangip@ietf.org
Subject: Re: [gaia] 5G: It's the Network, Stupid


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<mailto: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<mailto:gaia@irtf.org>
https://www.irtf.org/mailman/listinfo/gaia