Re: [Ideas] [5gangip] Comments to draft-vonhugo-5gangip-ip-issues-00

"David Lake (dlake)" <dlake@cisco.com> Wed, 21 September 2016 19:13 UTC

Return-Path: <dlake@cisco.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0E312B7DF; Wed, 21 Sep 2016 12:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.836
X-Spam-Level:
X-Spam-Status: No, score=-16.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 MHuFtFyMB2_E; Wed, 21 Sep 2016 12:13:24 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B919512B116; Wed, 21 Sep 2016 12:13:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27988; q=dns/txt; s=iport; t=1474485203; x=1475694803; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IdYdBwbYLe8fk8Vg3MxNhOYs0t4FHu+8Gafi9dcCI5M=; b=d8cX8vVORiHaj7Xgo+nqJnjpmhY986n1LY99DoLqlzHeh54E6XyRukd6 sPRDZIxvEiKTpyDl8taLzzCbKDbH4pz15R/xvc4dcnK9suTGESm44kA88 ullegZClqkdTOwmGIjF6lymKhfe1yeMhtLF2xIUs4MMIEv44OI0GTcsvS Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXAQB22uJX/5tdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgwc0AQEBAQEeV3wHjSyfAIxEggSGHgIcgUo4FAECAQEBAQEBAV4nhGE?= =?us-ascii?q?BAQEEIwpCChACAQgOAwEDAQEoAwICAh8RFAMGCAIEAQ0FCIgpAxevRokRDYMyA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHIY3hFSCR4FdLiiCToJaBYgvhz+EMIUiNQG?= =?us-ascii?q?MbYJtj3OIWIQPg3sBHjaFBXKFRn8BAQE?=
X-IronPort-AV: E=Sophos;i="5.30,375,1470700800"; d="scan'208,217";a="149736933"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2016 19:13:22 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u8LJDMdY020405 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Sep 2016 19:13:22 GMT
Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Sep 2016 15:13:21 -0400
Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1210.000; Wed, 21 Sep 2016 15:13:20 -0400
From: "David Lake (dlake)" <dlake@cisco.com>
To: Ca By <cb.list6@gmail.com>, Dino Farinacci <farinacci@gmail.com>
Thread-Topic: [Ideas] [5gangip] Comments to draft-vonhugo-5gangip-ip-issues-00
Thread-Index: AQHSFC5YYhOxV8BG60KGCVLCwHi7xKCEfY6A///MEkA=
Date: Wed, 21 Sep 2016 19:13:20 +0000
Message-ID: <b776ff07cf9e4007b75acdfa2f26a2a0@XCH-RTP-018.cisco.com>
References: <AA6C2C69-3B95-4F14-B301-2B7DB83D3373@gmail.com> <CAC8QAcca1fx-Z8b-Q_Kdv9_ETgjov9RsPt+CeDN5wrC=5WoTaw@mail.gmail.com> <29FC5745-22E5-4E0E-A918-822BD30DE610@gmail.com> <7cc516e0-b966-5ed0-55ed-f6e31ec90753@htt-consult.com> <CAD6AjGQqq2Y7a7GkRyxJbaQU+1D1+BNqQjhxDudr=rppvjzKOQ@mail.gmail.com> <BB0E6438-E1F4-4D46-AA71-BC5EAE009433@gmail.com> <CAD6AjGSF80EMy4fDv8CSGmVMXN2+j+V=q-o8RCVos_Lzx1RiJQ@mail.gmail.com>
In-Reply-To: <CAD6AjGSF80EMy4fDv8CSGmVMXN2+j+V=q-o8RCVos_Lzx1RiJQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.52.122]
Content-Type: multipart/alternative; boundary="_000_b776ff07cf9e4007b75acdfa2f26a2a0XCHRTP018ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/Y0m6N0dZ7NC_HN5r2WfcTWl3pvA>
X-Mailman-Approved-At: Wed, 21 Sep 2016 13:00:01 -0700
Cc: "ideas@ietf.org" <ideas@ietf.org>, AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>, Tom Herbert <tom@herbertland.com>, Robert Moskowitz <rgm@htt-consult.com>, Behcet Sarikaya <sarikaya@ieee.org>, "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>, David Meyer <dmm@1-4-5.net>, "5gangip@ietf.org" <5gangip@ietf.org>, Padma Pillay-Esnault <padma0528@gmail.com>, Richard Li <renwei.li@huawei.com>
Subject: Re: [Ideas] [5gangip] Comments to draft-vonhugo-5gangip-ip-issues-00
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2016 19:13:28 -0000

<dl> In-line </dl>

From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Ca By
Sent: 21 September 2016 18:56
To: Dino Farinacci <farinacci@gmail.com>
Cc: ideas@ietf.org; AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>om>; Tom Herbert <tom@herbertland.com>om>; Robert Moskowitz <rgm@htt-consult.com>om>; Behcet Sarikaya <sarikaya@ieee.org>rg>; Dirk.von-Hugo@telekom.de; David Meyer <dmm@1-4-5.net>et>; 5gangip@ietf.org; Padma Pillay-Esnault <padma0528@gmail.com>om>; Richard Li <renwei.li@huawei.com>
Subject: Re: [Ideas] [5gangip] Comments to draft-vonhugo-5gangip-ip-issues-00



On Wed, Sep 21, 2016 at 10:34 AM, Dino Farinacci <farinacci@gmail.com<mailto:farinacci@gmail.com>> wrote:
I get afraid that folks take this list too seriously. This list is simply a place to air "crazy ideas". Hopefully, a crazy idea that has potential gets traction, but i have not seen that yet.  I see the same old stale ideas that have failed in other venues get recycled and respun here.  More tunnels and more NAT to solve a problem we don't have....

But they are tools we have in our collective toolbox. Some tools don it work well for certain tasks.

I think the evolution within 3GPP is that the mobility system (GTP) is getting smaller and smaller, more and more distributed, so relevant innovation flows over the top, e2e gets restored....... If i am using netflix today on Wifi, and walk out the door and switch to LTE ... there is mobility there at the Netflix side....it just works ...  This is a problem solved at the application layer, we do not need complicated network layer things trying to insert themselves.

You are making a good point.

But it comes down to where you solve problems. And if you do it at the thin waist of the architecture then you solve mobility N times in each application.

i hear ya, but just like crypto / ipsec / TLS and, (gasp) multicast, the thin waist has proven too thin. Which is fine, thin is thin.


5G is simply millimeter wave small cell spectrum and marketing.

Well I think some people are trying also to make the 5G infra lower OpEx. Today the ~$50 cost to phone users can cover the infra costs. But what about when IoT devices which will be dirt cheap will need dirt cheap 5G service. Will that cover the high OpEx? Volume won't help the equation because greater scale will need to be dealt with.

<dl> Dino is correct (IMvHO).  5G is about more than mmWave – in fact, mmWave is probably just a way of avoiding the inevitable need to upgrade national infrastructure in terms of fibre roll-out…   And I am not sure that mmWave actually helps – you still need to install vast capacity to the local service nodes which have to be close to the premise so why not just add in the extra few metres and take it to the door and avoid all the vagaries of RF at those frequencies?

And it isn’t just about IoT devices which will need to be at SIGFOX type prices ($1/year for service is the rumoured price…)    Even $50 is VERY high – I pay £20/month for unlimited voice/text/data (actually capped at 50GB/month) and feel robbed at those prices (approx. US$32/month).   My son’s 6GB SIM plan which is bundled with our FTTC home service costs an additional £5/month over the broadband price.   With the (long overdue) EC regulation to remove roaming charges, we have to deliver lower TCO for the MSOs.

[And the UK is one of the most expensive LTE markets in the EU….]

</dl>

This is sort of where i was going with reducing the existing mobility system.  The cost comes from state and signalling of state, reducing the mobility system reduces the state and allows us to scale.

10 years ago, all mobile devices for a larger mobile network terminated in 2 national locations in the USA.

Now, greater than 20 locations.

In 5 years, termination of the mobility system may be at the cell sites for many cases (slices) while other slices require high level mobility management (state, costs, ...)

These IoT devices, just like my phone streaming Netflix, quasi-statelessly connects to the cloud.  Communication sessions are designed to be ephemeral, and thus take on some greater robustness properties.

<dl>  Doesn’t feel very robust to me at the moment, quite honestly.

As an example, I had a WebEx call yesterday which last 2 hours.   I started it at home on my phone with a voice service which called me back (so delivered over VoLTE).   I walked out of the house to catch the bus to my local railway station (dropped back to 3G) and got on the bus (which has WiFi) for the 10 minute journey to the station.   Got on a train to London (35 minute journey) during which time I moved between multiple 2G, 3G and 4G services.  And three tunnels where there was no service at all ☹

Got off at London Bridge and walked 20 minutes to my meeting – call stayed on VoLTE.

During that time, my “communication session” was VERY ephemeral – it dropped a total of 14 times and each time I had to do something different to restore it.  That is over a short ~30 mile commute.

We need to abstract the human communication piece from the underlying network substrate(s).

</dl>


Dino