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

Linda Dunbar <> Thu, 17 December 2015 21:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF3BF1B30CD; Thu, 17 Dec 2015 13:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fi1NmgRwHFPr; Thu, 17 Dec 2015 13:42:17 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77A951B30C5; Thu, 17 Dec 2015 13:42:17 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC20787; Thu, 17 Dec 2015 15:42:10 -0600 (CST)
Received: from ([]) by dfweml705-chm ([]) with mapi id 14.03.0235.001; Thu, 17 Dec 2015 13:42:04 -0800
From: Linda Dunbar <>
To: Dirk Kutscher <>, Ingemar Johansson S <>, "" <>, "" <>, gaia <>, "" <>, "" <>, "" <>
Thread-Topic: [5gangip] 5G: It's the Network, Stupid
Thread-Index: AdE4MC4YYpSof3RGRdK/YSjH5J56uAAY4/yAAAYu8OAAGZPx0A==
Date: Thu, 17 Dec 2015 21:42:03 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DB3C14@dfweml701-chm>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DB3C14dfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.56732C33.0064, 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: ad1711397763f3adf73d4708320029e6
Archived-At: <>
Subject: Re: [Stackevo-discuss] [5gangip] 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: Thu, 17 Dec 2015 21:42:22 -0000


Thanks for the interesting blog.

One comment on your writing: you notion of SDN is too narrowly focused.  SDN doesn't have to be OpenFlow.

SDN can be Application Controller (such as the CDN controller) using various hooks from the underlay network to achieve more efficient control of their own traffic.
The centralized controller will be service oriented. CDN's central controller is different from the Real Media central controller.

Linda Dunbar

From: Stackevo-discuss [] On Behalf Of Dirk Kutscher
Sent: Thursday, December 17, 2015 3:34 AM
To: Ingemar Johansson S;;; gaia;;;
Subject: Re: [Stackevo-discuss] [5gangip] 5G: It's the Network, Stupid

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.


From: Ingemar Johansson S []
Sent: Donnerstag, 17. Dezember 2015 08:26
To: Dirk Kutscher;<>;<>; gaia;<>;<>;<>
Cc: Ingemar Johansson S
Subject: RE: [5gangip] 5G: It's the Network, Stupid


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 ?.


From: Dirk Kutscher []
Sent: den 16 december 2015 19:41
To:<>;<>; gaia;<>;<>;<>
Subject: [5gangip] 5G: It's the Network, Stupid

[apologies for cross-posting]


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.

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.