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

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Sep 2016 09:15:04 -0700

Copying the list.

Dino

> On Sep 20, 2016, at 8:10 AM, Behcet Sarikaya <[email-masked]> wrote:
> 
> Hi Dino,
> 
> Please post your comments to the list, 5gangip.
> We may have answers, so it is better to discuss these things on our list the draft was announced.
> Actually the draft was intended to be a summary of the list discussion so far, we considered all the posts including from you when writing it.
> 
> Regards,
> 
> behcet

On Mon, Sep 19, 2016 at 6:03 PM, Dino Farinacci <[email-masked]> wrote:

I am copying others who may be interested in my commentary. Your ID text comes first indented and my comments follow.

> Abstract
> 
>    This document discusses considerations related to open and upcoming
>    issues with upcoming new communication systems denoted as 5G.  The

You could make this first sentence a bit more clear. How about:

This document discusses the problem space, use-cases and potential solutions related to supporting the next-generation mobile 5G communication infrastructure.

> 1.  Introduction
> 
>    This document focuses on IP architecture and protocol aspects related
>    to upcoming new communication system dubbed as 5G.  Originally

It is not dubbed 5G, IT IS the 5th generation mobile infrastructure. I would use a more direct term.

>    foreseen to be available from 2020 onwards such a converged ICT

Define ICT before using it.

>    Other key improvements which are not always direct quantitatively
>    measurable cover so-called soft features are also essential for 5G:
> 
>    o  Network scalability and flexibility
> 
>    o  Consistent customer experience
> 
>    o  Service and network trust, reliability and security
> 
>    o  Operational efficiency
> 
>    o  Openness for innovation

Do you want to include a bullet identifying slicing as a requirement. Because it appears as a solution to manage both UE and infrastructure resources as well as allowing for incremental deployability of new services. And you also mention it in section 7.

Also what is the hand-off latency? That is what is the tolerance for any packet loss. That needs to be quantified.

>    In this case, mobility issue will arise.  A cell phone moves, but its
>    identifier (ID) doesn't change.  Can we re-think about ID related
>    protocols such as LISP?  Can we re-scope it to just mobility?  ID

Well draft-meyer-lisp-mn has been around since 2009 so we thought about this a long time ago. So LISP doesn’t need to change to support cell phone moves.

I would suggest rephrasing the above reference to LISP to “Can LISP be used for this use-case?”.

>    plays a central role in mobility.  Can we design a new protocol, say
>    ID-Oriented Networking Protocol?  In future, more and more mobile
>    things are connected to the internet: connected cars, connected
>    drones, etc.

Note a cell phone today has so many identifiers already factory installed. It would be a pity to not use them for identifying connections or nodes. And an IMEI could be embedded into an IPv6 address if either LISP or ILA is used. 

>    For more discussion on this see Section 8.
> 
> 6.  Edge Network with no Tunneling
> 
>    In fixed network, PPPoE protocol [RFC2516] is used between the
>    residential gateway and broadband network gateway to transport the
>    residential users IP packets to the fixed network gateway to the
>    Internet.  PPPoE protocol requires 8 octets of header in every IP
>    packet, thereby reducing the MTU size by 8 octets to usually 1492
>    octets.  PPPoE protocol is carried in Ethernet frames with 18 octet
>    headers where the destination address is the broadband network
>    gateway address.

This is why it is good to consider BOTH ILA (a translation based mechanism) and LISP (an encapsulation based mechanism). Note they can BOTH be used for the data-plane areas in the network where you need smaller headers. But note they can BOTH use ONE control plane. That is what is important.

> von Hugo & Sarikaya      Expires March 18, 2017                 [Page 7]
> Internet-Draft                5G IP Issues                September 2016
> 
> 
>    In mobile network, IP packets are tunneled using GTP data plane
>    protocol called GTP-U.  First eNodeB or the base station tunnels UE's
>    IP packets to the Serving Gateway, in S1 GTP tunnel and then the
>    serving gateway tunnels to the Packet Gateway, called S5 tunnel.
>    Both of them are UDP tunnels which adds 8 octet header and GTP
>    protocl header is 12 octets, so a total of 20 octets are used.  In
>    addition also an IPSec header should be accounted for between eNodeB
>    and SGW.

Why not more end-to-end? That is on each end of the TCP connection would be the most optimal but at least from eNodeB to PGW perhaps.

>    Tunneling in both fixed and mobile networks has the purpose of
>    directing the user traffic to the correct gateway.  As exemplarily
>    shown above, however, tunneling adds a lot of overhead to the user IP
>    packets and therefore inefficiencies arise including reducing the MTU
>    size.

If you need to run ID/Loc separation in the UE itself, then use ILA. But if you don’t need to you can use LISP from sGW to pGW or all the way to to a data-center xTR or CPE xTR. 

I had a slide in 5gangip that showed all combinations where encapsulation could go.

But note tunneling is not required (and I wouldn’t suggest it), to run over the RAN. That can easily be avoided.

>    If tunneling can be avoided, i.e. if edge networks can be designed
>    with no tunneling, a corrollary of this would be no gateways would be
>    needed, leading to edge networks with no tunneling or no gateway.
>    The means to avoid gateways and tunneling a direct end-to-end routing
>    has to be established in the edge network.
> 
>    With routing support edge networks can direct the user traffic to the
>    correct destinations, rather than tunneling to the gateways.  In
>    order to deal with user mobility, ID-oriented networking protocol
>    would be needed.  So it needs to be evaluated if using ID-oriented
>    networking protocol with routing will lead to more efficient delivery
>    of user IP packets in the edge network compared with 4G edge network
>    techniques of tunneling with gateways.

You want the EPC (as well as the capital-I Internet) to not have to distribute and change state when a UE moves. It just can’t scale. And you will not get anything close to good handoff times.

> 8.  Location Identification Separation and Naming
> 
>    With both physical and logical mobility of (an extremely high number
>    of) entities and virtualization of network functions the traditional
>    usage of IP addresses for identification of name and address or
>    logical entity and location as source or destination of data packets

Be careful how you use names in this context. “Names” are human readable strings and are typically used by applications. We should really call a “network layer name” an “ID” or “EID”. Thereby distinguishing the functions of DNS versus a network-based database. They each serve different purposes.

See an enclosed slide for how I describe this in LISP.

>    becomes cumbersome.  New approaches to solve the issues are proposed
>    in LISP WG in terms of [RFC6830] and ICN RG (see [RFC7476]) but also
>    ILNP [RFC6740] and ILA [I-D.herbert-nvo3-ila] address this challenge.
> 
>    By separating a Routing LOCator (RLOC) from a unique Identity (EID)
>    LISP keeps a single address to each session endpoint even in multi-
>    homing but requires new mapping mechanisms at borders to the

It doesn’t matter WHERE the mapping is. The mechanisms (all of them) require a mapping function. Even if they are not map-n-encap proposals.

>    Internet.  ILNP (and ILNP-based ILA) do neither tunneling and
>    encapsulation nor require changes in higher layers (except the

In this context, you make it sound like tunneling and encapsulation are two different things. Is that what you intended?

>    transport layer) re-using part of an (IPv6) Address as Identifier and
>    Locator.
> 
>    LISP has two forms of split EID/RLOC collocated in same entity: EID
>    mobile, RLOC static.  Predictive RLOCs can be used if LISP entity

Cite the predictive-rloc draft.

RLOC can be dynamic too. Like a LISP xTR on a cable router where the RLOC is reassigned by the serivce provider the router connects to.

>    knows where the user going so that the system can mitigate mobility
>    impacts.  LISP can be used between the Serving and Packet data
>    Gateways.  Best solution is to keep LISP close to the moving entity
>    with the functions as close to the edge as possible.
> 
>    ILNP defines minimal changes on IPv4 and IPv6, it requires changes on

ILNP does not work on an IPv4 host. It is an IPv6 only solution, as it is spec’ed right now. Also true for ILA. There aren’t even bits (and motivation) to split up a 32-bit address into ID and Location parts.

>    the domain name system and the transport layer [RFC6740].  ILNP does
>    not require any changes on the routing system or LTE core network.

Both ILNP and ILA require the routing system to route to the translated address. Just like RLOCs must be in the routing system. So it is a wash IMO.

>    LISP requires routing system changes, it is implemented on the
>    routers, possibly on the edge routers.  That means LISP requires
>    changes on LTE core network.  ILNP does not use encapsulation so it
>    is light weight.  LISP is UDP encapsulated so in IPv6, LISP messages
>    incur 52 bytes of overhead.

This document should make it clear that if you are discussing ILNP and ILA and you want to use it for a host-based solution, then say so clearly. Because ILNP do have network proxies. And I’m not sure if ILA can do network proxies (or if Tom even wants to do it). And the document should make it clear, that if you are discussing LISP you want to use it as a router-based solution.

Because you are not just comparing a host versus router solution but AT THE SAME time a translation versus encapsulation. So to summarize:

o ILA is a host-based solution that uses translation.
o ILNP is a host or router based solution that uses translation.
o LISP is a host or router based solution that uses encapsulation.

And note above, we are talking about the data-plane only. And as I said, defining one control-plane could be used for all 5 combinations above.

>    ILNP nodes send Locator Update messages which are ICMPv4/v6 message
>    to its correspondent nodes when its Locator value changes during an
>    active session.  Correspondent node could be a fixed node such as
>    Google server which means ILNP has to be implemented by the fixed
>    nodes as well.
> 
>    ILA is a major update to ILNP [I-D.herbert-nvo3-ila].  It is

And a good one. It decouples itself from any one control-plane and deals with not needing DNS since it has the SIR prefix.

To make things simpler and to have less combinations to consider, I would suggest talking solely about ILA and LISP. And more importantly, how one can be used without the other, or both at the same time. That is, ILA can be used to save header space, and LISP may be needed to run IPv6 over some IPv4 infrastructure.

And I can see a situation where ILA may run OVER LISP. That is ILA IPv6 end-to-end but LISP in the middle. So you have the complementary solution that is host-based and network-based. ILA could do host multi-homing and LISP could do ISP network-based multihoming.

>    originally designed for network virtualization to be used in cloud
>    networks.  ILA can encode a virtual network identifier (VNID) and
>    virtual address as an ILNP identifier.  ILA can be adopted for
>    mobility and it can be applied to LTE network, the result can be
>    called mobile-ILA.  This effort is undergoing.  These aspects of ILA
>    are described in [I-D.mueller-ila-mobility].

So can LISP. So I suggest you do full disclosure. ;-)

>    Problem statement on the need for ID-oriented networking protocol,
>    exploiting LISP, ILNP and ILA efforts.

I think the document should be stronger and say whatever needs to be done to ILA and LISP to make it work for 5G should be done in their respective working groups (and intentionally leave out ILNP since it is so similar to ILA).

Thanks,
Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Sep 2016 10:07:18 -0700

Cross posting to this list.

Dino

> On Sep 20, 2016, at 9:15 AM, Dino Farinacci <[email-masked]> wrote:
> 
> Copying the list.
> 
> Dino
>

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 20 Sep 2016 10:20:07 -0700

On Tuesday, September 20, 2016 9:15 AM, Dino Farinacci wrote:
> ...
> Note a cell phone today has so many identifiers already factory installed. 
> It would be a pity to not use them for identifying connections or nodes. 
> And an IMEI could be embedded into an IPv6 address if either LISP or 
> ILA is used. 

And that would be a terrible privacy issue, allowing anybody on the path to track movements of the device, from routers to servers, spooks and hackers. There is a reason why the IPv6 working groups deprecated the usage of MAC addresses as node identifiers, and the same reasoning applies even more to IMEI.

-- Christian Huitema

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Sep 2016 10:27:28 -0700

> On Sep 20, 2016, at 10:20 AM, Christian Huitema <[email-masked]> wrote:
> 
> And that would be a terrible privacy issue, allowing anybody on the path to track movements of the device, from routers to servers, spooks and hackers. There is a reason why the IPv6 working groups 

The inner header is always encrypted and therefore obfuscated.

> deprecated the usage of MAC addresses as node identifiers, and the same reasoning applies even more to IMEI.

And guess what, they will make a come back since IoT challenged hardware doesn’t have to run IPv6-ND and suffer messaging latency.

Dino

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 20 Sep 2016 10:59:38 -0700

On Tuesday, September 20, 2016 10:27 AM, Dino Farinacci wrote:
> ...
> > And that would be a terrible privacy issue, allowing anybody on the path to
> track movements of the device, from routers to servers, spooks and hackers.
> There is a reason why the IPv6 working groups
> 

Well, it is visible by some nodes, isn't it? Like, visible by the end nodes, such as servers. Think advertising servers, tracking people across the web...

> And guess what, they will make a come back since IoT challenged hardware
> doesn’t have to run IPv6-ND and suffer messaging latency.

We are certainly having that debate too. I am not sure that the "IPv6-ND overhead" argument is valid -- the IOT devices are not resolving their own address, some kind of controller is. And in any case, that can be mitigated by using randomized MAC addresses.

Now, of course, we could consider using randomized IMEI. That would be a great improvement for mobile phone privacy.

-- Christian Huitema

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 20 Sep 2016 14:11:19 -0500

> Now, of course, we could consider using randomized IMEI. That would be a great improvement for mobile phone privacy.

I think that the above should be recorded in one of the documents we
mentioned in the draft,
  Requirements on a new ID-oriented network protocol

Regards,

Behcet
> -- Christian Huitema
>
>
>
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip

---

From: Padma <[email-masked]>
Date: Tue, 20 Sep 2016 10:31:52 -0700

CC'ing ideas as well

Sent from my iPhone

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 20 Sep 2016 22:00:38 +0100

On 20/09/16 18:59, Christian Huitema wrote:
>>> And that would be a terrible privacy issue, 

Fully agree.

>>> allowing anybody on
>>> the path to
>> track movements of the device, from routers to servers, spooks and
>> hackers. There is a reason why the IPv6 working groups
>> 
> Well, it is visible by some nodes, isn't it? Like, visible by the end
> nodes, such as servers. Think advertising servers, tracking people
> across the web...
> 
>>> deprecated the usage of MAC addresses as node identifiers, and
>>> the same
>> reasoning applies even more to IMEI.
>> 
>> And guess what, they will make a come back since IoT challenged
>> hardware doesn’t have to run IPv6-ND and suffer messaging latency.
> 
> We are certainly having that debate too. I am not sure that the
> "IPv6-ND overhead" argument is valid -- the IOT devices are not
> resolving their own address, some kind of controller is. And in any
> case, that can be mitigated by using randomized MAC addresses.
> 
> Now, of course, we could consider using randomized IMEI. That would
> be a great improvement for mobile phone privacy.

Randomised identifiers would be a significant improvement in
many protocols.

While visibly embedding long term fixed IMEIs and MAC addresses
in other protocols may have been acceptable years ago, that's
really no longer state of the art. Today, we should really be
thinking hard about which entities get to correlate identifiers
over time and space.

S.

> 
> -- Christian Huitema
> 
> 
> 
> _______________________________________________ 5gangip mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Sep 2016 16:24:04 -0700

> Well, it is visible by some nodes, isn't it? Like, visible by the end nodes, such as servers. Think advertising servers, tracking people across the web…

Depends how far the xTR is from the EID. It can be co-located with the application so a decrypted EID would only be in the application’s process space.

> We are certainly having that debate too. I am not sure that the "IPv6-ND overhead" argument is valid — 

Well let me help make it valid. No IPv6-ND is less overhead than running it. Agree?

> the IOT devices are not resolving their own address, some kind of controller is. And in any case, that can be mitigated by using randomized MAC addresses.

Not in the ITS use-case.

> Now, of course, we could consider using randomized IMEI. That would be a great improvement for mobile phone privacy.

Agree.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 20 Sep 2016 16:26:09 -0700

> Randomised identifiers would be a significant improvement in

See draft-farinacci-lisp-eid-anonymity.

> really no longer state of the art. Today, we should really be

It doesn’t have to be state of the art, if it works in use-cases of today.

Agree.

Dino

---

From: "MUELLER, JULIUS" <[email-masked]>
Date: Wed, 21 Sep 2016 16:03:59 +0000

A good reference and solution for the discussion below on “identifier” and “privacy” can be found under:
3GPP TS 23.003 (3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 14) 2.8 Globally Unique Temporary UE Identity (GUTI) https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=729#

Hereby, the GUTI is a temporary identify, which obfuscates the permanent identity in the mobile network.

The question will be: Which network element assigns the GUTI for the UE? In EPS it is either the 

(The concept of GUTI is part of the EPS and has been adopted in the ILA Mobility draft as well)

Best regards,
Julius

    
    
    S.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 21 Sep 2016 12:19:29 -0400

i have only made a quick pass through this document.  I will need to 
read it more closely, but...

I have major heartburn with how the paper places PPPoE and GTP-U. These 
technologies enjoy their widespread use as they simplify MONETIZING 
customer use of a shared resource.

Do not think you can talk them away.  In fact for my project I have been 
told not to expect any changes to GTP-U, other than perhaps having it 
terminate closer to the device.

Realize that if I can offer simple mobility between 2 devices on the 
same tower, that it will get rejected if there is no billing for that usage.

Any proposals here need to live with them or offer better charging 
business models with less network consumption that can then be used for 
more customers.

One of the mantras I faced regularly back in my Verizon days was 
Monetize-Monetize, or go away.  In fact there was loose talk that much 
of Verizon Enterprise Services was gutted (resulting in my 
organization's demise) due to poor monetizing efforts.

Bob

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 21 Sep 2016 11:26:13 -0500

Hi Julius,

People posting mails, please do not use long cc lists, the mailer is
complaining. Everyone is already on the list, we have more than 220
people now. Let's use the mailer to distribute.

> (The concept of GUTI is part of the EPS and has been adopted in the ILA Mobility draft as well)

Firstly, GUTI is 80 bits long, 48 bits so-called GUMMEI which
identifies the MME and 32 bits of so-called M-TMSI.
GUTI is used in signaling between EPS entities. It is designed for not
using IMSI in the EPS.

GUTI is assigned by MME during initial attach.

So it is specific to EPS of 3GPP.

Regards,
Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 21 Sep 2016 11:36:42 -0500

Hi Bob,

On Wed, Sep 21, 2016 at 11:19 AM, Robert Moskowitz <[email-masked]> wrote:
> i have only made a quick pass through this document.  I will need to read it
> more closely, but...
>
> technologies enjoy their widespread use as they simplify MONETIZING customer
> use of a shared resource.
>
> Realize that if I can offer simple mobility between 2 devices on the same
> tower, that it will get rejected if there is no billing for that usage.
>
> Any proposals here need to live with them or offer better charging business
> models with less network consumption that can then be used for more
> customers.
>
> Monetize-Monetize, or go away.  In fact there was loose talk that much of
> Verizon Enterprise Services was gutted (resulting in my organization's
> demise) due to poor monetizing efforts.
>

This is a good point. We have not considered charging, usually in IETF
we do not worry about such things which are actually very important :)

Actually what we said is:

So it needs to be evaluated if using ID-oriented
   networking protocol with routing will lead to more efficient delivery
   of user IP packets in the edge network compared with 4G edge network
   techniques of tunneling with gateways.

Maybe we should make it clearer in the next revision by adding
considerations like charging.

Regards,

Behcet

---

From: Ca By <[email-masked]>
Date: Wed, 21 Sep 2016 10:19:16 -0700

On Wed, Sep 21, 2016 at 9:19 AM, Robert Moskowitz <[email-masked]>
wrote:

> i have only made a quick pass through this document.  I will need to read
> it more closely, but...
>
+1

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

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.

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

Just my 2 cents.

CB

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Sep 2016 10:34:03 -0700

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

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

Dino

---

From: Ca By <[email-masked]>
Date: Wed, 21 Sep 2016 10:56:09 -0700

On Wed, Sep 21, 2016 at 10:34 AM, Dino Farinacci <[email-masked]>
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
> 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.

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

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.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 21 Sep 2016 11:21:36 -0700

On Wed, Sep 21, 2016 at 10:19 AM, Ca By <[email-masked]> wrote:
>> business models with less network consumption that can then be used for more
>> customers.
>>
> 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....
>

It may be solved in terms of functionality, but it is not solved in
terms of a seamless and low latency solution. In the Netflix case
there is a significant cost to creating a new connection, fortunately
when serving video that cost can be hidden from the user because of
buffering. In real time applications (like those that want to take
advantage of the proposed 1ms RTT in 5G) it is much harder problem.
New transport protocols like QUIC or TOU that use "disassociated
location" may be better but those require client side to send data to
servers after a moving to a new address or the server can't discover
the new address of the client. These solutions also require strong
security all the time. MPTCP is another option but that also has its
own drawbacks and requires support at client and server.

Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 21 Sep 2016 13:58:53 -0500

I repeat again, when posting please avoid long cc list!

On Wed, Sep 21, 2016 at 12:19 PM, Ca By <[email-masked]> wrote:
> I get afraid that folks take this list too seriously.

Cameron, thanks for taking us seriously :)

>his list is simply a

Agreed.

We took your advice from last year and dug through ILNP and similar in
search for a thin network layer protocol and that is where we are now.
We will appreciate your ideas at each step, please check things out
and help us with constructive comments.

Regards,

Behcet

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

Wow, this is big statement!

---

From: "David Lake (dlake)" <[email-masked]>
Date: Wed, 21 Sep 2016 19:13:20 +0000

<dl> In-line </dl>

From: Ideas [mailto:[email-masked]] On Behalf Of Ca By
Sent: 21 September 2016 18:56
To: Dino Farinacci <[email-masked]>
Cc: [email-masked]; AshwoodsmithPeter <[email-masked]>; Tom Herbert <[email-masked]>; Robert Moskowitz <[email-masked]>; Behcet Sarikaya <[email-masked]>; [email-masked]; David Meyer <[email-masked]>; [email-masked]; Padma Pillay-Esnault <[email-masked]>; Richard Li <[email-masked]>
Subject: Re: [Ideas] [5gangip] Comments to draft-vonhugo-5gangip-ip-issues-00

On Wed, Sep 21, 2016 at 10:34 AM, Dino Farinacci <[email-masked]<mailto:[email-masked]>> 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....

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.

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

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Sep 2016 13:59:10 -0700

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

And note, mobility just isn’t a feature in 5G. We want to roam within 5G, within WiFi, and across each technology. And there is BT, BLE, and LTE-NB coming. Just to name a few.

Right now the applications don’t help us out here (and they shouldn’t, this is a lower level problem). And, as David says, we humans have to “Tap on Settings, click Wifi, turn it off to use LTE, etc. 

Can you believe in the year 2016, we as users have to do this!

Dino

---

From: <[email-masked]>
Date: Thu, 22 Sep 2016 16:05:18 +0000

Hi Dino,
Thanks for the detailed review  - we will come back to your comments when revising the draft next time!

Best Regards
Dirk

From: Dino Farinacci [mailto:[email-masked]]
Sent: Dienstag, 20. September 2016 19:07
To: [email-masked]; [email-masked]
Cc: von Hugo, Dirk; Padma Pillay-Esnault; Richard Li; AshwoodsmithPeter; Tom Herbert; David Meyer; [email-masked]
Subject: Re: Comments to draft-vonhugo-5gangip-ip-issues-00

Dino

On Sep 20, 2016, at 9:15 AM, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

Copying the list.

Dino

On Sep 20, 2016, at 8:10 AM, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dino,

Regards,

behcet

On Mon, Sep 19, 2016 at 6:03 PM, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

Abstract

1.  Introduction

   o  Operational efficiency

Thanks,
Dino

---

From: <[email-masked]>
Date: Thu, 22 Sep 2016 16:28:26 +0000

Dear all,
Maybe your remark, Dino, on 'more than mobility and overarching connectivity' .... to be solved on - I would say: network - level ... is a good chance to remind of the original attempt of 5G-related discussion: to agree on a concrete work plan (see minutes of Berlin side meeting at https://mailarchive.ietf.org/arch/msg/5gangip/KL8oIichqzDjJyfyKSa8255wQP8)  - i.e. set of requirements, problem and solution space analysis ...

May we solicit volunteers to write drafts on that - so we can hope we have a chance at next IETF to go a step further towards scoping the needed work!? 

Thanks a lot!  

Best Regards
Behcet and Dirk 

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Mittwoch, 21. September 2016 22:59
To: David Lake (dlake)
Cc: [email-masked]; [email-masked]
Subject: Re: [5gangip] [Ideas] Comments to draft-vonhugo-5gangip-ip-issues-00

Dino