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

Dirk Kutscher <Dirk.Kutscher@neclab.eu> Thu, 17 December 2015 09:34 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 8218C1A871B; Thu, 17 Dec 2015 01:34:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 v2mk_CjDh9zR; Thu, 17 Dec 2015 01:34:24 -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 BF1AF1A8716; Thu, 17 Dec 2015 01:34:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9012F10B51E; Thu, 17 Dec 2015 10:34:21 +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 lnLdd54lzNnE; Thu, 17 Dec 2015 10:34:21 +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 625A710B51D; Thu, 17 Dec 2015 10:34:07 +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:34:07 +0100
From: Dirk Kutscher <Dirk.Kutscher@neclab.eu>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "icnrg@irtf.org" <icnrg@irtf.org>, "dtn-interest@irtf.org" <dtn-interest@irtf.org>, gaia <gaia@irtf.org>, "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" <marnew@iab.org>, "stackevo-discuss@iab.org" <stackevo-discuss@iab.org>
Thread-Topic: [5gangip] 5G: It's the Network, Stupid
Thread-Index: AdE4MC4YYpSof3RGRdK/YSjH5J56uAAY4/yAAAYu8OA=
Date: Thu, 17 Dec 2015 09:34:06 +0000
Message-ID: <82AB329A76E2484D934BBCA77E9F5249A683459F@Hydra.office.hd>
References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <81564C0D7D4D2A4B9A86C8C7404A13DA414EF289@ESESSMB208.ericsson.se>
In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA414EF289@ESESSMB208.ericsson.se>
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_82AB329A76E2484D934BBCA77E9F5249A683459FHydraofficehd_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gaia/ladw6DEgA9zNjxFPA8EpLIUah0Y>
Subject: Re: [gaia] [5gangip] 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:34:28 -0000

Hi Ingemar,

thanks for the feedback.

Yes, as far as I remember the UPCON work was rather on the traffic management side and may not have addressed the actual performance aspects (through AQM and ECN) sufficiently.

For ConEx, there haven't been enough experiments yet, unfortunately, but in my opinion the concept of "application-independent congestion accountability" for various use cases is really more promising than fine-granular traffic management. One of the use cases (that Bob came up with) is performance isolation in virtual networks, which would allow for a more flexible capacity sharing in data centers.

My point was if we are thinking about virtual slices, let's not introduce static QoS, bw reservations etc. for those applications that do not actually need it - there are other ways to share capacity.

Cheers,
Dirk


From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]
Sent: Donnerstag, 17. Dezember 2015 08:26
To: Dirk Kutscher; icnrg@irtf.org; dtn-interest@irtf.org; gaia; 5gangip@ietf.org; marnew@iab.org; stackevo-discuss@iab.org
Cc: Ingemar Johansson S
Subject: RE: [5gangip] 5G: It's the Network, Stupid

Hi

Thanks for an interesting blog post. Parts of this is above my head so I only comment on the parts that I know well
AQM and ECN : Agree fully, there seems to be a general tendency to overlook the basic elements in congestion management in networks. Quite often  one see reports of roundtrip times of 1 second or more in LTE networks. High RTT was also part of the problem formulation in the UPCON WI but as I recall it, the role of (lack of) AQM and ECN  was missed.
ConEx : What is your view of ConEx ?. The work is wrapping up, but as I see it the interest in the "end to end" ConEx is quite modest. Do you envision more local deployments like what is outlined in draft-ietf-conex-mobile ?.

/Ingemar

From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu]
Sent: den 16 december 2015 19:41
To: icnrg@irtf.org<mailto:icnrg@irtf.org>; dtn-interest@irtf.org<mailto:dtn-interest@irtf.org>; gaia; 5gangip@ietf.org<mailto:5gangip@ietf.org>; marnew@iab.org<mailto:marnew@iab.org>; stackevo-discuss@iab.org<mailto:stackevo-discuss@iab.org>
Subject: [5gangip] 5G: It's the Network, Stupid

[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