Subject: Re: [5gangip] MINUTES of side meeting in Singapore

From: Uma Chunduri <[email-masked]>
Date: Tue, 5 Dec 2017 21:24:27 +0000

From: 5gangip [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, November 29, 2017 9:42 AM
To: Ca By <[email-masked]>; [email-masked]
Cc: [email-masked]; Bill Gage <[email-masked]>; Satoru Matsushima <[email-masked]>; Tom Herbert <[email-masked]>
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

> One could describe the efforts here as naive hubris, but i'll admit that is sometimes what innovation looks like. But, please consider that the 3gpp mobility system is not a wifi hotspot, it identifies 5 generations of radio systems and connects billions of users with global mobility.... and billing... and Lawful Intercept and ....    It is 20+ years old, and has layer upon layers of features / tech debt.

Yes. Its a very complex system. But, I always though, at least of some of that complexity is also by design and was used as a vendor-lock, so no new players can get in so easily.
Looking at what we can do today with unlicensed Wi-Fi radio in enterprises and the applications we can support, vs. the complexity with 3GPP system using a licensed radio, there is no comparison.

[Uma]: Fully agree and am not sure then how the discussions in the list would be eventually helpful to have meaningful conclusion..

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Dec 2017 10:07:17 +0100

Le 05/12/2017 à 22:24, Uma Chunduri a écrit :
> *From:*5gangip [mailto:[email-masked]] *On Behalf Of *Sri 
> Gundavelli (sgundave) *Sent:* Wednesday, November 29, 2017 9:42 AM 
> *To:* Ca By <[email-masked]>; [email-masked] *Cc:*
> [email-masked]; Bill Gage <[email-masked]>; Satoru Matsushima
> <[email-masked]>; Tom Herbert <[email-masked]> 
> *Subject:* Re: [5gangip] MINUTES of side meeting in Singapore
> 
>> One could describe the efforts here as naive hubris, but i’ll admit
>> that
> is sometimes what innovation looks like. But, please consider that
> the 3gpp mobility system is not a wifi hotspot, it identifies 5
> generations of radio systems and connects billions of users with
> global mobility.... and billing... and Lawful Intercept and ....
> It is 20+ years old, and has layer upon layers of features / tech
> debt.
> 
> Yes. Its a very complex system. But, I always though, at least of
> some of that complexity is also by design and was used as a
> vendor-lock, so no new players can get in so easily.
> 
> Looking at what we can do today with unlicensed Wi-Fi radio in 
> enterprises and the applications we can support, vs. the complexity
> with 3GPP system using a licensed radio, there is no comparison.
> 
> [Uma]: Fully agree and am not sure then how the discussions in the
> list would be eventually helpful to have meaningful conclusion..

What has been said already since Singapour could be synthesized in a
white paper.

"5GANGIP perspective on 5G and Next Generation Internet" could be a
title, and the content could describe these topics:
- 5G networks defined at 3GPP (and why not IEEE 5G too)
- 5G deployment timelines
- business barriers of entry, comparison to WiFi deployments
- SRH vs huge 3GPP stacks
- id-loc overall concept, with history
- id-loc protocols: LISP, ILA, ILNP (if I am not wrong)
- id-loc state maintenance throughout Internet
- id-loc multicast
- id-loc privacy
- requirements for multiple IDs and LOCs per nodes
- recent trials of 5G: 3.5GHz BLR LTE, 1GBps UE modems, bandwidth
   aggregation, 5G demo at Winter Olympics.

As you can see there are many interesting topics.

Alex

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

---

From: <[email-masked]>
Date: Wed, 6 Dec 2017 10:13:45 +0000

Hi Alex, all
That sounds like a detailed plan (and a great bunch of work)! ;-)
Do we have already volunteers to contribute?
If not implicitly included in the topics below I would also add 
 - estimation of selected key performance indicators behavior in 5G as a function of different protocols' usage (for a selected scenario) 
Where from some pro and con arguments could be derived (hopefully)
Thanks!
Best Regards
Dirk 

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Mittwoch, 6. Dezember 2017 10:07
To: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Le 05/12/2017 à 22:24, Uma Chunduri a écrit :
>> One could describe the efforts here as naive hubris, but i'll admit 
>> that
> is sometimes what innovation looks like. But, please consider that the 
> 3gpp mobility system is not a wifi hotspot, it identifies 5 
> Yes. Its a very complex system. But, I always though, at least of some 
> of that complexity is also by design and was used as a vendor-lock, so 
> no new players can get in so easily.
> 

What has been said already since Singapour could be synthesized in a white paper.

"5GANGIP perspective on 5G and Next Generation Internet" could be a title, and the content could describe these topics:

Alex

> [email-masked] https://www.ietf.org/mailman/listinfo/5gangip

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

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 6 Dec 2017 12:14:34 +0000

Dirk - I can take the role of editor along with you or any other volunteer for such a white paper.

Kalyani Bogineni
Verizon

________________________________

From: "[email-masked]" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 6, 2017 at 5:14:09 AM
To: "[email-masked]" <[email-masked]<mailto:[email-masked]>>, "[email-masked]" <[email-masked]<mailto:[email-masked]>>
Subject: [E] Re: [5gangip] MINUTES of side meeting in Singapore

Hi Alex, all

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Mittwoch, 6. Dezember 2017 10:07
To: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Alex

> [email-masked] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=eeg3ZBsywkh4uWSBbLDO4hJREzkc3qb9O6qDegtRsP4&s=yzG7r3K25Qii_55AM97pHVO2vaBUxLNwyx112Ihput0&e=
>

_______________________________________________
5gangip mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=eeg3ZBsywkh4uWSBbLDO4hJREzkc3qb9O6qDegtRsP4&s=yzG7r3K25Qii_55AM97pHVO2vaBUxLNwyx112Ihput0&e=

_______________________________________________
5gangip mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=eeg3ZBsywkh4uWSBbLDO4hJREzkc3qb9O6qDegtRsP4&s=yzG7r3K25Qii_55AM97pHVO2vaBUxLNwyx112Ihput0&e=

---

From: Bill Gage <[email-masked]>
Date: Wed, 6 Dec 2017 14:35:21 +0000

Hello Alex -

You seem to be equating Next Generation Internet with id-loc solutions. Perhaps that should be the first discussion -- what will be the dominant protocols in the Internet-at-large over the next 5-10 years. I suggest that things like IPv6 multihoming via host-specific prefix assignment, QUIC, HTTP/2, and SR will have more influence than yet-another overlay mobility solution, whether it is based on id-loc protocols or something else.

A whitepaper describing existing id-loc solutions will only preach to the converted ;-)

Cheers ... 

/bill

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, December 06, 2017 4:07 AM
To: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Alex

---

From: Tom Herbert <[email-masked]>
Date: Wed, 6 Dec 2017 07:20:25 -0800

> You seem to be equating Next Generation Internet with id-loc solutions. Perhaps that should be the first discussion -- what will be the dominant protocols in the Internet-at-large over the next 5-1…
Bill,

I disagree. IMO we should be building an Internet that supports all
transport protocols, security protocols, and applications not just
those that are in vogue, a few select vendors want to contol, or what
the government wants. A good overlay solution a layer 3 provides
mobility for that goal. IPv6 is the relevant network layer protocol
for this work.

W.r.t SR, IMO unless the proponents can figure out a way to robustly
do extension header insertion (see discussion in 6man), it's doubful
the mechanism will ever have any serious influence on the Internet.

Tom

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 6 Dec 2017 15:59:41 +0000

All applications need to work on all access technologies (be decoupled). This is why overlay approaches are by far the predominant method for video/voice/chat etc. 

Their deployment is massive already.

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Bill Gage
Sent: Wednesday, December 06, 2017 9:35 AM
To: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Hello Alex -

Cheers ... 

/bill

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, December 06, 2017 4:07 AM
To: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Alex

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 6 Dec 2017 19:04:25 +0000

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Bill Gage
Sent: Wednesday, December 06, 2017 6:35 AM
To: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Hello Alex -

You seem to be equating Next Generation Internet with id-loc solutions. Perhaps that should be the first discussion -- what will be the dominant protocols in the Internet-at-large over the next 5-10 years. 
I suggest that things like IPv6 multihoming via host-specific prefix assignment, QUIC, HTTP/2, and SR will have more influence than yet-another overlay mobility solution, whether it is based on id-loc protocols or something else.

[Uma]:   Bill, Couple of things.

                    1. Some form of IETF stuff, TLS1.3 (native + EAP mode), QUICK and HTTP/2 (control plane especially between all virtualized modules, Nx, Ny... interfaces) + enhanced EAP methods would be there in 5G (though not decided fully yet by 3GPP)
                    2.  Mobility has always been a network based solution home grown there with GTP and for various not-so-technical reasons it continue to be defined that way even in 5G. 
                         I see there is a scope given the complexity with new mobility use cases + low latency and increased scale requirements for new schemes. But I am quite sure that *won't be* host based,  given how it has always been.
                   3. Coming to SR - yes this would play a role too in the backhaul transport from eNB/gNB to UPF. Probably both SR-MPLS and SR-IPv6 (though more hurdles there, w.r.t both extension headers realities, size and may be performance) 
                        and this is the closest one can get for slicing dreams with all its warts (RSVP won't cut it). Here there are lot of gaps but those would be taken care slowly (see VPN+ for example).

    #1 stuff is designed and developed by IETF not for 3GPP but 3GPP would potentially use it. This is by far the preferred model for them if 3G, 4G is any guide to us.
    #2 is where this group wants to contribute but I would fully agree with the earlier emails on ground realities of 3GPP w.r.t innovation (its constrained, legacy and regulated environment).
            I guess, best bet would be to start and address few practical issues without being seen as these solutions doesn't fit into "3GPP architecture". 
           Network based ID/LOC overlay solution IMO have huge potential there.
    #3 is transport IP network and its IETFs home turf; but not relevant in this list.

Cheers ... 

/bill

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, December 06, 2017 4:07 AM
To: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Alex

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 6 Dec 2017 19:15:06 +0000

+1 

One comment:
I would prefer this instead of describing the whole history of ID/LOC protocols (summary and key pointers would be good enough), we ought to focus on key value proposition those can bring in that environment. 
We also ought to think where mapping server has to be for example and should start with key use cases where a particular problem is solved better than they have. I can lay out one such use case...

--
Uma C.

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 06, 2017 2:14 AM
To: [email-masked]; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Hi Alex, all
That sounds like a detailed plan (and a great bunch of work)! ;-) Do we have already volunteers to contribute?
If not implicitly included in the topics below I would also add
 - estimation of selected key performance indicators behavior in 5G as a function of different protocols' usage (for a selected scenario) Where from some pro and con arguments could be derived (hopefully) Thanks!
Best Regards
Dirk 

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Mittwoch, 6. Dezember 2017 10:07
To: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Alex

---

From: Bill Gage <[email-masked]>
Date: Wed, 6 Dec 2017 21:57:03 +0000

Hello Uma -
	Just to clarify, I didn't suggest that the alternate mobility solutions would be host based but there are different models for how much the host participates in the solution. 

3GPP has defined several session and service continuity models for 5G that offer trade-offs in their capabilities and in how much work is done by the host and by the network. You see similar trade-offs in the various flavours of IETF mobility management protocols as well.

#2 may be where this group *wants* to contribute, but I question whether yet-another mobility solution would be addressing the pressing needs of the industry. Don't kid yourself, 3GPP is moving much faster on the innovation front than IETF -- they just don't bother re-inventing the wheel if the existing solutions work just fine.

Cheers ... 

/bill

-----Original Message-----
From: Uma Chunduri 
Sent: Wednesday, December 06, 2017 2:04 PM
To: Bill Gage <[email-masked]>; Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: RE: [5gangip] MINUTES of side meeting in Singapore

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Bill Gage
Sent: Wednesday, December 06, 2017 6:35 AM
To: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Hello Alex -

 

Cheers ... 

/bill

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, December 06, 2017 4:07 AM
To: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Alex

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 6 Dec 2017 22:14:03 +0000

Bill,

>#2 may be where this group *wants* to contribute, but I question whether yet-another mobility solution would be addressing the pressing needs of the industry

I guess, this is not been evaluated or evaluated/compared (not only among the ID/LOC but with the existing solutions in 3GPP) well enough and the proposed white paper doesn't hurt to see this aspect more throughly among other things.
Yes, I am well aware, it would be brown field there..

Cheers!

--
Uma C.

---

From: Arashmid Akhavain <[email-masked]>
Date: Thu, 7 Dec 2017 16:14:33 +0000

I am with Uma here. The white paper should be able to clearly state the benefits of replacing GTP based data path with ID/LOC encapsulation + mapping system approach. How about migration path? Should the white paper also talk about migration path?

As for the mapping servers location, they could be either place close to access (CRANs provide good opportunity here), or they can exist 
in DCs centres reachable by the access.

Arashmid

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: 06 December 2017 14:15
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

+1

One comment:

--
Uma C.

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 06, 2017 2:14 AM
To: [email-masked]; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Hi Alex, all

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Mittwoch, 6. Dezember 2017 10:07
To: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Dec 2017 17:43:47 +0100

Le 07/12/2017 à 17:14, Arashmid Akhavain a écrit :
> I am with Uma here. The white paper should be able to clearly state
> the benefits of replacing GTP based data path with ID/LOC
> encapsulation + mapping system approach. How about migration path?
> Should the white paper also talk about migration path?

Migration from GTP to ID/LOC encapsulatin you mean?

> As for the mapping servers location, they could be either place close
> to access (CRANs provide good opportunity here), or they can exist in
> DCs centres reachable by the access.

I can agree.
Dino provided great initial schémas of where id-loc entities could be 
situated in a 5G core network.  However, that could have more impact if 
it were drawn using a more 3GPP style: black and white, rectangles 
instead of ovals, etc.  Just some thought.

Alex

> 
> Arashmid
> 
> 
> -----Original Message----- From: 5gangip
> [mailto:[email-masked]] On Behalf Of Uma Chunduri Sent: 06
> December 2017 14:15 To: [email-masked];
> [email-masked]; [email-masked] Subject: Re: [5gangip]
> MINUTES of side meeting in Singapore
> 
> +1
> 
> One comment: I would prefer this instead of describing the whole
> history of ID/LOC protocols (summary and key pointers would be good
> enough), we ought to focus on key value proposition those can bring
> in that environment. We also ought to think where mapping server has
> to be for example and should start with key use cases where a
> particular problem is solved better than they have. I can lay out one
> such use case...
> 
> -- Uma C.
> 
> 
> -----Original Message----- From: 5gangip
> [mailto:[email-masked]] On Behalf Of
> [email-masked] Sent: Wednesday, December 06, 2017 2:14 AM 
> To: [email-masked]; [email-masked] Subject: Re:
> [5gangip] MINUTES of side meeting in Singapore
> 
> Hi Alex, all That sounds like a detailed plan (and a great bunch of
> work)! ;-) Do we have already volunteers to contribute? If not
> implicitly included in the topics below I would also add - estimation
> of selected key performance indicators behavior in 5G as a function
> of different protocols' usage (for a selected scenario) Where from
> some pro and con arguments could be derived (hopefully) Thanks! Best
> Regards Dirk
> 
> -----Original Message----- From: 5gangip
> [mailto:[email-masked]] On Behalf Of Alexandre Petrescu 
> Sent: Mittwoch, 6. Dezember 2017 10:07 To: [email-masked] Subject:
> Re: [5gangip] MINUTES of side meeting in Singapore
> 
> 
> 
>> *From:*5gangip [mailto:[email-masked]] *On Behalf Of
>> *Sri Gundavelli (sgundave) *Sent:* Wednesday, November 29, 2017
>> 9:42 AM *To:* Ca By <[email-masked]>; [email-masked] *Cc:* 
>> [email-masked]; Bill Gage <[email-masked]>; Satoru
>> Matsushima <[email-masked]>; Tom Herbert
>> <[email-masked]> *Subject:* Re: [5gangip] MINUTES of side
>> meeting in Singapore
>> 
>>> One could describe the efforts here as naive hubris, but i'll
>>> admit that
>> global mobility.... and billing... and Lawful Intercept and .... It
>> is 20+ years old, and has layer upon layers of features / tech 
>> debt.
>> 
>> enterprises and the applications we can support, vs. the
>> complexity with 3GPP system using a licensed radio, there is no
>> comparison.
>> 
> title, and the content could describe these topics: - 5G networks
> defined at 3GPP (and why not IEEE 5G too) - 5G deployment timelines -
> business barriers of entry, comparison to WiFi deployments - SRH vs
> huge 3GPP stacks - id-loc overall concept, with history - id-loc
> protocols: LISP, ILA, ILNP (if I am not wrong) - id-loc state
> maintenance throughout Internet - id-loc multicast - id-loc privacy -
> requirements for multiple IDs and LOCs per nodes - recent trials of
> 5G: 3.5GHz BLR LTE, 1GBps UE modems, bandwidth aggregation, 5G demo
> at Winter Olympics.
> 
>> _______________________________________________ 5gangip mailing
>> list [email-masked]

---

From: Arashmid Akhavain <[email-masked]>
Date: Thu, 7 Dec 2017 20:37:39 +0000

Yes, that's what I meant by migration. IMO two systems can easily coexist. 5G slicing can come handy here as well.

Arashmid

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: 07 December 2017 11:44
To: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

> DCs centres reachable by the access.

I can agree.
Dino provided great initial schémas of where id-loc entities could be situated in a 5G core network.  However, that could have more impact if it were drawn using a more 3GPP style: black and white, rectangles instead of ovals, etc.  Just some thought.

Alex

> enough), we ought to focus on key value proposition those can bring in 
> that environment. We also ought to think where mapping server has to 
> be for example and should start with key use cases where a particular 
> problem is solved better than they have. I can lay out one such use 
> case...
> 
> -- Uma C.
> 
> 
> of selected key performance indicators behavior in 5G as a function of 
> different protocols' usage (for a selected scenario) Where from some 
> pro and con arguments could be derived (hopefully) Thanks! Best 
> Regards Dirk
> 
>> Gundavelli (sgundave) *Sent:* Wednesday, November 29, 2017
>> is 20+ years old, and has layer upon layers of features / tech debt.
>> 
> 5G: 3.5GHz BLR LTE, 1GBps UE modems, bandwidth aggregation, 5G demo at 
> Winter Olympics.
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 7 Dec 2017 21:00:27 +0000

Before we talk about replacing GTP, using mapping servers, ID-LOC or some
solution, can some one explain the key problems in today¹s mobile
architectures? What are the aspects that you think are fundamental drivers
for next-gen architecture ? Please, lets avoid solution discussion and may
be talk about requirements.

1.) Is optimized routing the absolute key goal here? Drivers for this? Is
it for reducing latency? Any numbers on latency in today¹s architecture?
2.) Perhaps, state reduction in the user plane network. But, can we
identify those specific state elements and quantify the goals?
3.) Off course, cut the cost of the UPF (no argument here)
4.) How willing are operators to change today¹s charging or other models,
which brought much of the complexity. Ex: No need for per-byte accounting,
its flat charge. Any simplification there which drives many of the user
plane features?

For my own understandingŠ

Sri

On 12/7/17, 8:14 AM, "5gangip on behalf of Arashmid Akhavain"
<[email-masked] on behalf of [email-masked]> wrote:

>I am with Uma here. The white paper should be able to clearly state the
>benefits of replacing GTP based data path with ID/LOC encapsulation +
>mapping system approach. How about migration path? Should the white paper
>also talk about migration path?
>
>As for the mapping servers location, they could be either place close to
>access (CRANs provide good opportunity here), or they can exist
>I would prefer this instead of describing the whole history of ID/LOC
>protocols (summary and key pointers would be good enough), we ought to
>focus on key value proposition those can bring in that environment.
>We also ought to think where mapping server has to be for example and
>should start with key use cases where a particular problem is solved
>better than they have. I can lay out one such use case...
>
>--
>Uma C.
>
>
> - estimation of selected key performance indicators behavior in 5G as a
>function of different protocols' usage (for a selected scenario) Where
>from some pro and con arguments could be derived (hopefully) Thanks!
>Best Regards
>Dirk 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Dec 2017 09:37:45 +0100

Le 07/12/2017 à 22:00, Sri Gundavelli (sgundave) a écrit :
> architectures?

- IPv6 is only partially deployed in mobile networks: the GTP tunnel
   transports IPv6 in IPv4.
- NAT64 and 464XLAT have huge security problems with DNS, with many
   applications, and other problems.
- there are way too many layers in the 3GPP stack.
- Mobile IP and Proxy Mobile IP are not deployed in mobile networks.

For me these are good starting points to think of problems in today's 
mobile architectures.

> What are the aspects that you think are fundamental drivers

These two points are worth exploring.

> 3.) Off course, cut the cost of the UPF (no argument here)

UPF?

> its flat charge. Any simplification there which drives many of the user

I am not sure about the charging consideration at mobile operator.

But I notice general tendency in recent years to (1) reduce the overall 
subscription costs down to formulas of 1eur/month even sometimes free of 
charge and (2) simplify the accounting significantly, away from need of 
counting bytes: 'flat' rates and (3) reduce significantly the number of 
kinds of subscription plans and (4) roaming agreements in Europe 
eliminating the supplimentary charges.

Today, one complexity still in place is this 'fair-use' limit.  An 
excellent 'fair-use' limit is 50GB/month at some operator.  After 
downloading that amount, the bandwidth is 'throttled' down, and user 
experiences delays.  Operators compete on who offers a higher 'fair-use' 
before throttling arrives.  It was 3Mbit/s at the first 4G trials in 
2010 and slowly evolved to a max 50GBit/s today.

A 'fair-use' limit would be extremely complex to implement when the 
traffic is aggregated on 2.GHz, 3.5GHz and unlicensed 5GHz.

A 'fair-use' limit of 50GB/month on 4G+ 300Mbit/s has less sense on 5G 
1Gbit/s bandwidth.

That's why it will disappear.

Alex

---

From: <[email-masked]>
Date: Fri, 8 Dec 2017 08:58:48 +0000

Hi Alex,

Quick reply if your question was on definition and role of UPF = User Plane Function as defined in 3GPP for Next Generation (common) Core:
Having all UP forwarding and packet modification instead in hardwired S/P-GW now in flexible SDN/NFV-based infrastructure ... and this UPF is thought to be controlled by separate CPF for Session Management (SMF) ... as is currently assumed. 
More to be found e.g. at http://www.3gpp.org/ftp/Specs/latest-drafts/23501-150.zip 

Best Regards
Dirk 
-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Freitag, 8. Dezember 2017 09:38
To: Sri Gundavelli (sgundave) <[email-masked]>; Arashmid Akhavain <[email-masked]>; Uma Chunduri <[email-masked]>; von Hugo, Dirk <[email-masked]>; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Le 07/12/2017 à 22:00, Sri Gundavelli (sgundave) a écrit :
> Before we talk about replacing GTP, using mapping servers, ID-LOC or 
> some solution, can some one explain the key problems in today¹s mobile 
> architectures?

For me these are good starting points to think of problems in today's mobile architectures.

> What are the aspects that you think are fundamental drivers for 
> next-gen architecture ? Please, lets avoid solution discussion and may 
> 1.) Is optimized routing the absolute key goal here? Drivers for this? 
> Is it for reducing latency? Any numbers on latency in today¹s architecture?

UPF?

> 4.) How willing are operators to change today¹s charging or other 
> models, which brought much of the complexity. Ex: No need for per-byte 
> accounting, its flat charge. Any simplification there which drives 
> many of the user plane features?

But I notice general tendency in recent years to (1) reduce the overall subscription costs down to formulas of 1eur/month even sometimes free of charge and (2) simplify the accounting significantly, away from need of counting bytes: 'flat' rates and (3) reduce significantly the number of kinds of subscription plans and (4) roaming agreements in Europe eliminating the supplimentary charges.

Today, one complexity still in place is this 'fair-use' limit.  An excellent 'fair-use' limit is 50GB/month at some operator.  After downloading that amount, the bandwidth is 'throttled' down, and user experiences delays.  Operators compete on who offers a higher 'fair-use' 
before throttling arrives.  It was 3Mbit/s at the first 4G trials in
2010 and slowly evolved to a max 50GBit/s today.

A 'fair-use' limit would be extremely complex to implement when the traffic is aggregated on 2.GHz, 3.5GHz and unlicensed 5GHz.

A 'fair-use' limit of 50GB/month on 4G+ 300Mbit/s has less sense on 5G 1Gbit/s bandwidth.

Alex

>> protocols (summary and key pointers would be good enough), we ought 
>> to focus on key value proposition those can bring in that environment.
>> That sounds like a detailed plan (and a great bunch of work)! ;-) Do 
>>we  have already volunteers to contribute?
>> - estimation of selected key performance indicators behavior in 5G as 
>>a  function of different protocols' usage (for a selected scenario) 
>>Where from some pro and con arguments could be derived (hopefully) Thanks!
>> Best Regards
>> Dirk
>>
>>> <[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Dec 2017 15:12:07 +0100

[...]

> 
> Second, the emergency call numbers are far from being unified.
> 
> <dl> Agreed, but this is nothing to do with connectivity.  112 has
> been standardised across the EU for a number of years.<dl>

I dont trust 112.  I have tried it, it did not answer.  I waited 2-3
seconds and then hanged.  I dont even know whether it's a free or paid
number.   I rather called the country-level emergency number, for which
I am sure, and it's only two digits to dial, instead of three.

Similary, yesterday I saw an ambulance on the road displaying a big
'911'.  It's the company name, not the number to dial; it has to do with
the '91' being the department number.  It's a huge mislead for someone
used to 911 of America.

In many hotels rooms one must dial '9' to get ouf of the hotel.  Adding
11 is not helping.  One has to dial '9911' if you are in America, or
'9112' if you are in Europe.

On another hand, few will mistake facebook for something else.

> 
> What if 'global roaming' meant just one cheap wifi device with IP
> addresses, straight routing, VoIP and facebook for emergency calls.
> 
> <dl> My experience of WiFi is it does not offer the quality of
> service I expect (and get) from LTE.  Voice quality is awful on many
> VoIP sessions  with packet-drops and re-rates of the codec.  As a
> musician, I find this INCREDIBLY frustrating and annoying - I will
> often ask people to revert to a "lower-quality" connection that
> remains at a constant quality.   This can be evidenced in the
> reduction of quality of outside broadcast interviews on radio
> programmes as the broadcasters now grapple with
> unreliable/packet-loosing IP sessions rather than the ISDN links they
> used to rely on.  </dl>
> 
>> with the EU directive now fully implemented and several MNOs
>> extending that to non-EU countries, I really find I don’t think
>> about roaming any more (at least to the destinations I go which is
>> the US and with the EU).
> 
> Inter-country roaming in Europe - true, it saw significant leaps
> recenty, butstill has issues.
> 
> The most advanced roaming agreements still miss this or that other
> country in Europe.
> 
> <dl> Covers all EU states last time I checked?</dl>

Depends what one considers "EU states", but the new roaming agreements
still do not cover places that could easily be considered as situated in
Europe like Switzerland, Serbia, Groenland, ex-Yugoslavia, Belarus, some
Latvia, Moldova and probably others.

> They have a lesser fair-use limits than in-country, most performant
> peaking at 50GB/duration, where duration varies.  This limit could be
> noticed if you have a webradio in your car (not FM radio), listen to
> a 5.1 192khz web streamed radio, and commute in a cross-border area.
> 
> <dl> I haven't listened to FM radio for many years - the main station
> I listen to is BBC Radio 3 which (mostly) uses an AAC-coded multiplex
> on the national DAB multiplex.  192kbit/s compared to FM is pretty
> awful - the digital artefacts are very noticeable and annoying.
> Even 320kbit/s AAC on DAB is hard-work to listen to for a while (if
> you want a proof point here, listen to applause on FM, 320kbit/s DAB
> and 192kbit/s stream and you'll find that the FM is more comfortable
> on the brain with the 192kbit/s being really broken).
> 
> As an aside, this year, the BBC ran a lossless streaming service for
> the Proms which was superb.  I was in the US for several concerts
> (bad planning) and ended up trying to stream across WiFi - it didn’t
> work well (kept buffering).   LTE roaming worked perfectly...</dl>

I can agree with the reasoning on the codecs and quality.

But my speculation is that if one were to run that BBC lossless
streaming service 24h a day while roaming, one would reach the fair use
limit long before the 3 months of 'free of charge' of the LTE subscription.

Alex

---

From: Bill Gage <[email-masked]>
Date: Fri, 8 Dec 2017 14:51:18 +0000

> IPv6 is only partially deployed in mobile networks: the GTP tunnel transports IPv6 in IPv4.

You have to make a distinction between "deployed on mobile devices" and "deployed in the mobile network infrastructure".

*All* of the major cellular carrier -- who are often also wireline ISPs -- have already migrated to IPv6 in their infrastructure or are in the process of doing so. While 3GPP currently supports both IPv4 and IPv6 in the network transport layer, there is an expectation that IPv6 will be the dominant deployment option for 5G.

In the 5G study item phase, there was discussion of supporting only IPv6 but there was nothing defined that depended on IPv6-specific capabilities and, so, both IPv4 and IPv6 are supported. That may change if there is a new feature introduced that specifically builds on an IPv6-specific capability.

On mobile devices, the situation is a bit different since the network needs to support legacy devices that may not support IPv6. In these cases, IPv4 user data is tunnelled in a GTP-over-IPv6 packet. IPv6 user data in a GTP-over-IPv4 tunnel will be a rarity.

> there are way too many layers in the 3GPP stack.

(user data)/GTP/UDP/IP. Other than IP-in-IP, this looks like a basic transport protocol stack. 

Cheers ... 

/bill

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday, December 08, 2017 3:38 AM
To: Sri Gundavelli (sgundave) <[email-masked]>; Arashmid Akhavain <[email-masked]>; Uma Chunduri <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

UPF?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Dec 2017 16:12:34 +0100

Le 08/12/2017 à 15:51, Bill Gage a écrit :
[...]
> In the 5G study item phase, there was discussion of supporting only
> IPv6 but there was nothing defined that depended on IPv6-specific
> capabilities and, so, both IPv4 and IPv6 are supported. That may
> change if there is a new feature introduced that specifically builds
> on an IPv6-specific capability.

That specific feature is IPv6 itself: larger address space can 
accommodate more machines including virtual, remote management through a 
maze of layers, and more.

Another advantage is that IPv6-in-IPv6 (and not IPv6-in-GTP-UDP/IPv4) is 
well documented and tested for interoperability at IETF; that can reduce 
significantly the cost of bare platforms in the network.

I continue be surprised at how this IPv4 question is still there in 
mobile networks.

> On mobile devices, the situation is a bit different since the network
> needs to support legacy devices that may not support IPv6. In these
> cases, IPv4 user data is tunnelled in a GTP-over-IPv6 packet.

I think there is no 3GPP spec that says "GTP-over-IPv6".  Further, I 
think it says GTP is _only_ UDP/IPv4.

> IPv6
> user data in a GTP-over-IPv4 tunnel will be a rarity.

I agree.

> transport protocol stack.

Well, Satoru displayed a graphic with much more layers.  If only we had 
an ASCII version to paste here.

Alex

---

From: Ca By <[email-masked]>
Date: Fri, 08 Dec 2017 15:18:06 +0000

> - IPv6 is only partially deployed in mobile networks: the GTP tunnel

This does not matter to users or operators. Users get e2e ipv6, and the
transport network between the base station and the gateway is only the
operators business.  They are free to use whatever transport fits.

>    applications, and other problems.

Disagree. DNSSEC has caused more problems (misconfigurations outages, ddos
amplification) than it has solved (had dnssec prevented any real world
attack? Really?)

In any event, plaintext passwords is a huge security issue. Unsigned dns
record for ipv4-only resources is not a huge issue. The obvious fix, if the
resource is on any value, is to use ipv6 — problems solved and dns64
avoided.

> - there are way too many layers in the 3GPP stack.

Subjective, each layer has a function.

> - Mobile IP and Proxy Mobile IP are not deployed in mobile networks.

This is a feature, not an flaw.

---

From: <[email-masked]>
Date: Fri, 8 Dec 2017 16:32:42 +0000

Alexandre

PMIP is used in cellular networks to provide mobility capabilities between 802.11 and LTE attach (Trusted and Untrusted Wireless access in 3GPP terms). 

Mobile IP is not needed in the cellular network because GTP tunnel movement effectively does the same thing.

At the moment, the proposal for the UPF is to retain a tunnel (which can be GTP or PMIP) between UE and anchor point.  There really aren't any more (or less) layers in current cellular infrastructure than there are in a wireline network.

One issue we do have is the extreme over-loading of header vs payload - the cost of processing multiple headers when the payload is large and long-lived (e.g. video) is justifiable; it is not economically viable if the data is a once-every-few-hours 2 byte temperature reading in IoT.  The energy used to process that compared with the intrinsic worth of the data is out of balance.

In terms of the cost-justification, you are slightly incorrect that it was roaming agreements that brought down the cost of EU roaming - the agreements had always been in place but they were seen primarily as a cash-cow for the operators.  It was an EU directive, 2016/2286, we have to thank for that.

I suspect (and hope) that the "fair-use" clauses will prove to be equally as unjustifiable in the long-term.  

If what I suspect will happens happens and we move from the current competitive transport model with OTT to a single transport model with applications, then counting bytes will become more important, not less, as when you pay to access content, there will be a settlement to the transport operator in much the same way as happens now when you buy electricity from an end supplier and it is transported over the common infrastructure to your home/business.

David

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: 08 December 2017 08:38
To: Sri Gundavelli (sgundave) <[email-masked]>; Arashmid Akhavain <[email-masked]>; Uma Chunduri <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

UPF?

Alex

---

From: Bill Gage <[email-masked]>
Date: Fri, 8 Dec 2017 16:47:42 +0000

> I think there is no 3GPP spec that says "GTP-over-IPv6".  Further, I think it says GTP is _only_ UDP/IPv4.

LTE TS 36.424 quote "The eNB shall support IPv6 (IETF RFC 2460 [5]) and/or IPv4 (IETF RFC 791 [6])".
LTE TS 36.414 quote "The eNB and the EPC shall support IPv6 (IETF RFC 2460 [5]) and/or IPv4 (IETF RFC 791 [6])".
5G  TS 38.424 quote "The gNB shall support IPv6 (IETF RFC 2460 [5]) and/or IPv4 (IETF RFC 791 [6])".
5G  TS 38.414 quote "The gNB/ng-eNB and the 5GC shall support IPv6 (IETF RFC 2460 [5]) and/or IPv4 (IETF RFC 791 [6])".

> Well, Satoru displayed a graphic with much more layers.  

That chart was probably describing protocol layers over the air interface between a gNB and a UE. Those protocols are not conveyed between RAN and CN.

> I continue be surprised at how this IPv4 question is still there in mobile networks.

It's called "backward compatibility" ... a serious concern for businesses with a large installed base involving billions of users ;-)

Cheers ... 

/bill

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Friday, December 08, 2017 10:13 AM
To: Bill Gage <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>; Arashmid Akhavain <[email-masked]>; Uma Chunduri <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

> on an IPv6-specific capability.

That specific feature is IPv6 itself: larger address space can accommodate more machines including virtual, remote management through a maze of layers, and more.

Another advantage is that IPv6-in-IPv6 (and not IPv6-in-GTP-UDP/IPv4) is well documented and tested for interoperability at IETF; that can reduce significantly the cost of bare platforms in the network.

I continue be surprised at how this IPv4 question is still there in mobile networks.

> cases, IPv4 user data is tunnelled in a GTP-over-IPv6 packet.

I think there is no 3GPP spec that says "GTP-over-IPv6".  Further, I think it says GTP is _only_ UDP/IPv4.

I agree.

> transport protocol stack.

Well, Satoru displayed a graphic with much more layers.  If only we had an ASCII version to paste here.

Alex

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 8 Dec 2017 10:17:59 -0800

> 5G  TS 38.414 quote "The gNB/ng-eNB and the 5GC shall support IPv6 (IETF RFC 2460 [5]) and/or IPv4 (IETF RFC 791 [6])”.

I wish they had not used this language “and/or”. Because it may presume to vendors not to do IPv6. It should have said “support for IPv6 required and optionally also IPv4”.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Dec 2017 12:00:13 -0800

> I wish they had not used this language “and/or”. Because it may presume to vendors not to do IPv6. It should have said “support for IPv6 required and optionally also IPv4”.
Discussions are underway to sunset IPv4
(https://datatracker.ietf.org/wg/sunset4/about/). Forward-looking
technologies really be putting IPv6 first.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 8 Dec 2017 12:29:28 -0800

> technologies really be putting IPv6 first.

Agree but I wouldn’t use “sunsetting” either. I would say IPv4 is “mid afternoon”. :-)

Dino

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Dec 2017 12:31:33 -0800

> Agree but I wouldn’t use “sunsetting” either. I would say IPv4 is “mid afternoon”. :-)
It will be a twenty year sunset, but the message should now be clear :-)

---

From: "Schumacher L." <[email-masked]>
Date: Fri, 8 Dec 2017 22:37:00 +0100

Dear Alexandre,

> had an ASCII version to paste here.

 From a message dating back November 13, 2017:

+----------------+  ///////////////////////////
|  User Payload  |  ///////////////////////////
+----------------+  ---------------------------
| IPv6 SA (128)  |
+----------------+  IPv6 as User PDN Protocol
| IPv6 DA (128)  |
+----------------+  ---------------------------
| Tunnel ID (32) |
+----------------+
| UDP SPort (16) |
+----------------+  GTPv1U as Mobile User-Plane
| UDP DPort (16) |  Protocol
+----------------+  Multiplexes Sessions in
|   IP SA (32)   |  a Tunnel Between Two Nodes
+----------------+
|   IP DA (32)   |
+----------------+  ---------------------------
| VPN Label (20) |
+----------------+
| LSP Label (20) |  Deploys Mobile Back-haul
+----------------+  and Core w/ High Quality
|  VLAN ID (12)  |  and Reliability
+----------------+  For C/U-Plane and O&M
|    SMAC (48)   |  Networks
+----------------+
|    DMAC (48)   |
+----------------+  ---------------------------
| VPN Label (20) |  Multiple Virtual Networks
+----------------+  Co-exist, Provides High
| LSP Label (20) |  Quality and Reliability
+----------------+  ---------------------------
|    SMAC (48)   |  ///////////////////////////
+----------------+  ///////////////////////////
|    DMAC (48)   |  ///////////////////////////
+----------------+  ///////////////////////////

Eventually, this is a regular TCP/IP stack but, as David Lake puts it, 
the issue is "the extreme over-loading of header vs payload".

Best regards,
LS
-- 

Laurent SCHUMACHER
Professeur
Faculté d'Informatique

T. +32 (0)81 724 980
F. +32 (0)81 724 967
[email-masked] <mailto:[email-masked]>
http://www.unamur.be/universite/personnes/page_view/01005249/
http://be.linkedin.com/pub/laurent-schumacher/0/32b/7b7

Université de Namur ASBL
Rue de Bruxelles 61 - 5000 Namur

Let’s respect the environment together.
Only print this message if necessary!

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 8 Dec 2017 22:32:30 +0000

..

Eventually, this is a regular TCP/IP stack but, as David Lake puts it, the issue is "the extreme over-loading of header vs payload".

+1

Yes and there are projected, *huge* (really huge) number of fixed 5G connections (IoTs) where  most of the time data is 1 or 2 byte keepalives.
For that even the actual IPv6 UE header is also seems like overhead. But if you bear with it, you have to add these layers…

Also it’s not shown, but:
Both the LSP labels would multiple (mostly, with slicing) as these would be non-shortest-paths/crafted paths.
Because the figure included the above portion i.e, a shared transport network reality being used multiple operators; there is one more overhead of IPSec-ESP from eNB to SGW for sure (not present in the diagram).

Overall, this is transport network underlay with anchor point reality out there. So unfortunately, some of what won’t go anywhere soon!

--
Uma C.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 8 Dec 2017 20:17:41 -0800

With GTP-U overhead, the LISP overhead is looking pretty darn good/small. A fixed 36 bytes if the outer header is IPv4.

<ipv4-header><udp-header><lisp-header><payload>
   20-bytes     8-bytes     8-bytes  

With arguably all the same features (including crypto) as this GTP-U header.

Dino

> On Dec 8, 2017, at 2:32 PM, Uma Chunduri <[email-masked]> wrote:
> 
> ..

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 9 Dec 2017 10:46:43 +0100

given the (alleged) latency requirement for 5G, can I suggest also that
this definitely looks a lot less unlikely than some of the other
approaches, too...

On Sat, Dec 9, 2017 at 5:17 AM, Dino Farinacci <[email-masked]> wrote:

> With GTP-U overhead, the LISP overhead is looking pretty darn good/small.
> A fixed 36 bytes if the outer header is IPv4.
>
> > Yes and there are projected, *huge* (really huge) number of fixed 5G
> connections (IoTs) where  most of the time data is 1 or 2 byte keepalives.
> > For that even the actual IPv6 UE header is also seems like overhead. But
> if you bear with it, you have to add these layers…
> >
> > Because the figure included the above portion i.e, a shared transport
> network reality being used multiple operators; there is one more overhead
> of IPSec-ESP from eNB to SGW for sure (not present in the diagram).
> >
> > Overall, this is transport network underlay with anchor point reality
> out there. So unfortunately, some of what won’t go anywhere soon!
> >
> > --
> > Uma C.
> >
> >
> >
> >

---

From: <[email-masked]>
Date: Sat, 9 Dec 2017 10:41:08 +0000

“Alleged” is the operative word.

Is the limiting factor for the low-latency requirement (which I have yet to see a convincing case for but, although ever sceptical, I am always open to persuasion) the transport protocol or is it the placement of the terminating application in relation to the client?

If the latter, then frankly the transport protocol characteristics are unlikely to be material especially if the use-case which is oft touted (VR/AR) is the predominant low-latency application as we will be considering large payloads cf the headers.

Much of that discussion is in the NetSlices proto-WG and, as I have stated before, this group and NetSlices are tackling different portions of the same problem space and should be considered together.

Mobility events become the biggest issue in edge use-cases and there we may need richness in the transport protocol.

I can see far more justification for tunnel(s) replacement if we take the network/energy efficiency argument for small-packet IoT (much of which will be non-IP) than if we try and justify based on latency.

D

Sent from my iPhone
________________________________
From: 5gangip <[email-masked]> on behalf of Jon Crowcroft <[email-masked]>
Sent: Saturday, December 9, 2017 9:46:43 AM
To: Dino Farinacci
Cc: [email-masked]; Schumacher L.; Uma Chunduri
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

given the (alleged) latency requirement for 5G, can I suggest also that this definitely looks a lot less unlikely than some of the other approaches, too...

On Sat, Dec 9, 2017 at 5:17 AM, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:
With GTP-U overhead, the LISP overhead is looking pretty darn good/small. A fixed 36 bytes if the outer header is IPv4.

Dino

> On Dec 8, 2017, at 2:32 PM, Uma Chunduri <[email-masked]<mailto:[email-masked]>> wrote:
>
> ..
> [email-masked]<mailto:[email-masked]>

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 9 Dec 2017 13:18:08 +0100

Le 08/12/2017 à 17:32, [email-masked] a écrit :
> Alexandre
> 
> PMIP is used in cellular networks to provide mobility capabilities
> between 802.11 and LTE attach (Trusted and Untrusted Wireless access
> in 3GPP terms).

If possible, provide a pointer to an operator that implements PMIP as 
mentioned above.

(not the pointer to specification).

This can be very useful in my experimentations.

> Mobile IP is not needed in the cellular network because GTP tunnel
> movement effectively does the same thing.

Right.  And whereas at IETF we do know how Mobile IP works - RFC numbers 
for Mobile IP - we do not know how GTP works - there is no GTP RFC.

This is a strange situation.

> At the moment, the proposal for the UPF is to retain a tunnel (which
> can be GTP or PMIP) between UE and anchor point.

But, neither GTP nor PMIP tunnels are on UE.  What do you mean?

> There really aren't
> any more (or less) layers in current cellular infrastructure than
> there are in a wireline network.

I doubt that.  The packet dumps I have seen captured on PGW do show some 
redundant layers.

For example, even a simple IP-in-IP encapsulation is redundant in such a 
small network that an operator network is (small compared to the size of 
the Internet).  IP encapsulation is relevant _only_ if the network is 
large and route updates are impossible.

> One issue we do have is the extreme over-loading of header vs payload
> - the cost of processing multiple headers when the payload is large
> and long-lived (e.g. video) is justifiable; it is not economically
> viable if the data is a once-every-few-hours 2 byte temperature
> reading in IoT.  The energy used to process that compared with the
> intrinsic worth of the data is out of balance.

I agree.  It is an important issue.

> In terms of the cost-justification, you are slightly incorrect that
> it was roaming agreements that brought down the cost of EU roaming -
> the agreements had always been in place but they were seen primarily
> as a cash-cow for the operators.  It was an EU directive, 2016/2286,
> we have to thank for that.

YEs, but it is not enough.  IT is still a cash-cow.  As long as Android 
has easily accessed buttons saying 'turn mobile data off' it means that 
there is a risk of spending too much money while roaming.

> I suspect (and hope) that the "fair-use" clauses will prove to be
> equally as unjustifiable in the long-term.
> 
> If what I suspect will happens happens and we move from the current
> competitive transport model with OTT to a single transport model with
> applications, then counting bytes will become more important, not
> less, as when you pay to access content, there will be a settlement
> to the transport operator in much the same way as happens now when
> you buy electricity from an end supplier and it is transported over
> the common infrastructure to your home/business.

I have read it.

Alex

> Sent: 08 December 2017 08:38 To: Sri Gundavelli (sgundave)
> <[email-masked]>; Arashmid Akhavain
> <[email-masked]>; Uma Chunduri
> <[email-masked]>; [email-masked];
> [email-masked] Subject: Re: [5gangip] MINUTES of side meeting in
> Singapore
> 
>> Before we talk about replacing GTP, using mapping servers, ID-LOC
>> or some solution, can some one explain the key problems in today¹s
>> mobile architectures?
> 
> transports IPv6 in IPv4. - NAT64 and 464XLAT have huge security
> problems with DNS, with many applications, and other problems. -
> there are way too many layers in the 3GPP stack. - Mobile IP and
> Proxy Mobile IP are not deployed in mobile networks.
> 
>> next-gen architecture ? Please, lets avoid solution discussion and
>> may be talk about requirements.
>> 
>> 1.) Is optimized routing the absolute key goal here? Drivers for
>> this? Is it for reducing latency? Any numbers on latency in today¹s
>> architecture? 2.) Perhaps, state reduction in the user plane
>> network. But, can we identify those specific state elements and
>> quantify the goals?
> 
>> models, which brought much of the complexity. Ex: No need for
>> per-byte accounting, its flat charge. Any simplification there
>> which drives many of the user plane features?
> 
> But I notice general tendency in recent years to (1) reduce the
> overall subscription costs down to formulas of 1eur/month even
> sometimes free of charge and (2) simplify the accounting
> significantly, away from need of counting bytes: 'flat' rates and (3)
> reduce significantly the number of kinds of subscription plans and
> (4) roaming agreements in Europe eliminating the supplimentary
> charges.
> 
> experiences delays.  Operators compete on who offers a higher
> 'fair-use' before throttling arrives.  It was 3Mbit/s at the first 4G
> trials in 2010 and slowly evolved to a max 50GBit/s today.
> 
>>> I am with Uma here. The white paper should be able to clearly
>>> state the benefits of replacing GTP based data path with ID/LOC 
>>> encapsulation + mapping system approach. How about migration
>>> path? Should the white paper also talk about migration path?
>>> 
>>> As for the mapping servers location, they could be either place
>>> close to access (CRANs provide good opportunity here), or they
>>> can exist in DCs centres reachable by the access.
>>> 
>>> Arashmid
>>> 
>>> 
>>> [mailto:[email-masked]] On Behalf Of Uma Chunduri Sent:
>>> 06 December 2017 14:15 To: [email-masked];
>>> [email-masked]; [email-masked] Subject: Re:
>>> history of ID/LOC protocols (summary and key pointers would be
>>> good enough), we ought to focus on key value proposition those
>>> can bring in that environment. We also ought to think where
>>> mapping server has to be for example and should start with key
>>> use cases where a particular problem is solved better than they
>>> have. I can lay out one such use case...
>>> 
>>> -- Uma C.
>>> 
>>> 
>>> [email-masked] Sent: Wednesday, December 06, 2017 2:14
>>> AM To: [email-masked]; [email-masked] Subject:
>>> Hi Alex, all That sounds like a detailed plan (and a great bunch
>>> of work)! ;-) Do we  have already volunteers to contribute? If
>>> not implicitly included in the topics below I would also add -
>>> estimation of selected key performance indicators behavior in 5G
>>> as a  function of different protocols' usage (for a selected
>>> scenario) Where from some pro and con arguments could be derived
>>> (hopefully) Thanks! Best Regards Dirk
>>> 
>>> [mailto:[email-masked]] On Behalf Of Alexandre
>>> Petrescu Sent: Mittwoch, 6. Dezember 2017 10:07 To:
>>> [email-masked] Subject: Re: [5gangip] MINUTES of side meeting
>>> in Singapore
>>> 
>>> 
>>> 
>>>> 9:42 AM *To:* Ca By <[email-masked]>; [email-masked]
>>>> *Cc:* [email-masked]; Bill Gage <[email-masked]>;
>>>> Satoru Matsushima <[email-masked]>; Tom Herbert 
>>>> is sometimes what innovation looks like. But, please consider
>>>> that the 3gpp mobility system is not a wifi hotspot, it
>>>> identifies 5 generations of radio systems and connects billions
>>>> of users with global mobility.... and billing... and Lawful
>>>> Intercept and .... It is 20+ years old, and has layer upon
>>>> layers of features / tech debt.
>>>> 
>>>> Yes. Its a very complex system. But, I always though, at least
>>>> of some of that complexity is also by design and was used as a 
>>>> [Uma]: Fully agree and am not sure then how the discussions in
>>>> the list would be eventually helpful to have meaningful
>>>> conclusion..
>>> 
>>> "5GANGIP perspective on 5G and Next Generation Internet" could be
>>> a title, and the content could describe these topics: - 5G
>>> networks defined at 3GPP (and why not IEEE 5G too) - 5G
>>> deployment timelines - business barriers of entry, comparison to
>>> WiFi deployments - SRH vs huge 3GPP stacks - id-loc overall
>>> concept, with history - id-loc protocols: LISP, ILA, ILNP (if I
>>> am not wrong) - id-loc state maintenance throughout Internet -
>>> id-loc multicast - id-loc privacy - requirements for multiple IDs
>>> and LOCs per nodes - recent trials of 5G: 3.5GHz BLR LTE, 1GBps
>>> UE modems, bandwidth aggregation, 5G demo at Winter Olympics.
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 9 Dec 2017 13:21:20 +0100

> 5G  TS 38.414 quote "The gNB/ng-eNB and the 5GC shall support IPv6 (IETF RFC 2460 [5]) and/or IPv4 (IETF RFC 791 [6])".

But, that is not GTP.  It is IPv6-carried-in-GTP-carried-in-UDP/IPV4. 
Right?

Besides, no 5G document should still say RFC2460, but RFC8200.

> That chart was probably describing protocol layers over the air interface between a gNB and a UE. Those protocols are not conveyed between RAN and CN.

I doubt that.  The UE does not do many layers.  It just does IPv6.

Alex

---

From: <[email-masked]>
Date: Sat, 9 Dec 2017 14:46:03 +0000

<dl> in-line </dl>

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: 09 December 2017 12:18
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

> between 802.11 and LTE attach (Trusted and Untrusted Wireless access 

If possible, provide a pointer to an operator that implements PMIP as mentioned above.

<dl> I know of one UK operator who run a service for VoIP which roams between WiFI and LTE but the service is being discontinued... </dl>

> movement effectively does the same thing.

Right.  And whereas at IETF we do know how Mobile IP works - RFC numbers for Mobile IP - we do not know how GTP works - there is no GTP RFC.

<dl> Agree.  But this speaks more to the relationship between 3GPP and IETF than to the state of the protocols.   In this respect, 3GPP is a "user" community who have chosen what they feel are appropriate protocols.  It is a very strange situation, but the organisation and rationale of the two SDOs is very, VERY different.  </dl>

<dl> Correct - the tunnel between the UE and the eNB is a PDCP.  So the traffic from the UE in IP could be considered to be "tunnelled" by different stacks in the same way that traffic from a PC to a web server is tunnelled differently.   The difference is that the PDCP layer is managed in a mobile network by the same entities which mange the internal network tunnels, so although different encapsulations, you could think of there being a contiguous pipe from UE data to SGi anchor-point.  </dl>

> there are in a wireline network.

I doubt that.  The packet dumps I have seen captured on PGW do show some redundant layers.

For example, even a simple IP-in-IP encapsulation is redundant in such a small network that an operator network is (small compared to the size of the Internet).  IP encapsulation is relevant _only_ if the network is large and route updates are impossible.

<dl>  I don't know - there are some amazingly complex peering arrangements and tunnels out there, especially in Enterprise networks crossing continental paths.   It is a wonder some of them work at all or can be fixed when something goes wrong! </dl>

> In terms of the cost-justification, you are slightly incorrect that it 
> was roaming agreements that brought down the cost of EU roaming - the 
> agreements had always been in place but they were seen primarily as a 
> cash-cow for the operators.  It was an EU directive, 2016/2286, we 
> have to thank for that.

YEs, but it is not enough.  IT is still a cash-cow.  As long as Android has easily accessed buttons saying 'turn mobile data off' it means that there is a risk of spending too much money while roaming.

<dl> Well, we are not in peak holiday period, so at least in the UK, there is not as much comment on "rip-off" roaming as there would be if it were July or August.... 😊   However, the removal of the roaming boundaries has caused a major change in the economics of the operators.  There are some markets where things are not like this (I was in Canada over the summer holidays and was shocked how much people pay for mobile service - I've always thought of the US as over-priced, but Canada took this to another, eye-watering level!) </dl>

> less, as when you pay to access content, there will be a settlement to 
> the transport operator in much the same way as happens now when you 
> buy electricity from an end supplier and it is transported over the 
> common infrastructure to your home/business.

I have read it.

<dl> Standard disclaimer - I am a simple Engineer, not an Economist 😊 </dl>

Alex

> <[email-masked]>; [email-masked]; [email-masked] 
>> some solution, can some one explain the key problems in today¹s 
>> mobile architectures?
> 
> problems with DNS, with many applications, and other problems. - there 
> are way too many layers in the 3GPP stack. - Mobile IP and Proxy 
> Mobile IP are not deployed in mobile networks.
> 
>> architecture? 2.) Perhaps, state reduction in the user plane network. 
>> But, can we identify those specific state elements and quantify the 
>> goals?
> 
>> per-byte accounting, its flat charge. Any simplification there which 
>> drives many of the user plane features?
> 
>>> close to access (CRANs provide good opportunity here), or they can 
>>> exist in DCs centres reachable by the access.
>>> 
>>> Arashmid
>>> 
>>> 
>>> particular problem is solved better than they have. I can lay out 
>>> one such use case...
>>> 
>>> -- Uma C.
>>> 
>>> 
>>> To: [email-masked]; [email-masked] Subject:
>>> implicitly included in the topics below I would also add - 
>>> estimation of selected key performance indicators behavior in 5G as 
>>> a  function of different protocols' usage (for a selected
>>> Sent: Mittwoch, 6. Dezember 2017 10:07 To:
>>>> *Cc:* [email-masked]; Bill Gage <[email-masked]>; Satoru 
>>> defined at 3GPP (and why not IEEE 5G too) - 5G deployment timelines 
>>> - business barriers of entry, comparison to WiFi deployments - SRH 
>>> vs huge 3GPP stacks - id-loc overall concept, with history - id-loc 
>>> maintenance throughout Internet - id-loc multicast - id-loc privacy 
>>> - requirements for multiple IDs and LOCs per nodes - recent trials 
>>> of 5G: 3.5GHz BLR LTE, 1GBps UE modems, bandwidth aggregation, 5G 
>>> demo at Winter Olympics.
>>> 
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/5gangip
>>>> 
>>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sat, 9 Dec 2017 16:12:38 +0000

>(not the pointer to specification).

We may be going on a tangent and probably an unnecessary discussion. But I
do want to correct the above statement that you may be hinting at.

It is given GTP is THE protocol in all core 3GPP interfaces and there is
no debate about it. That battle is over and IETF failed to promote Mobile
IP based architecture (which was the basis in CDMA) to LTE when there was
an opportunity. 
Except for probably NTT Docomo’s initial S5 based PMIP deployment, and few
S2a based eHRPD/LTE interworking deployments, all are GTP that is the
active protocol today in packet core deployments. We also had Wi-MAX which
was using PMIPv6 for, but we all know the story there with WiMAX’ short
fame.

At the same time, I do want you to know there are large scale Service
Provider deployments based on PMIPv6, by Cable MSO’s and in other
architectures. Million’s of CPE’s are running PMIP MAG code and supporting
Wi-Fi services. Applications such as, Service Provider Wi-Fi, Private
Routing Over LTE, Mobile Networks are some of the use-cases based on this
protocol. It is also absolutely correct there are few Trusted Wi-Fi
deployments which use S2a-based PMIP for interconnecting Wi-Fi access to
EPC. This does not take away the fact that its GTP that is the protocol in
EPC today, but lets get the facts right.

Also, IETF may have failed in applying mobility protocol in 3GPP, but many
of the protocols that are fundamental to 3GPP architecture including SIP,
EAP, DHCP-PD, IPv6, TLS .. and number of other protocols are based on the
work that came out of IETF. I do not know why, but we some how always
undersell IETF when it comes to 3GPP discussion.

Sri

---

From: Tom Herbert <[email-masked]>
Date: Sat, 9 Dec 2017 08:13:05 -0800

On Sat, Dec 9, 2017 at 2:41 AM,  <[email-masked]> wrote:
> Is the limiting factor for the low-latency requirement (which I have yet to
> see a convincing case for but, although ever sceptical, I am always open to
> persuasion) the transport protocol or is it the placement of the terminating
> application in relation to the client?
>
> If the latter, then frankly the transport protocol characteristics are
> unlikely to be material especially if the use-case which is oft touted
> (VR/AR) is the predominant low-latency application as we will be considering
> large payloads cf the headers.
>
> Much of that discussion is in the NetSlices proto-WG and, as I have stated
> before, this group and NetSlices are tackling different portions of the same
> problem space and should be considered together.
>
> I can see far more justification for tunnel(s) replacement if we take the
> network/energy efficiency argument for small-packet IoT (much of which will
> be non-IP) than if we try and justify based on latency.
>
David,

ILA is zero bytes of overhead. There is no encapsulation, no use of
extension headers, and no requirement to upgrade existing network
hardware. A TCP/IP packet with an ILA address looks like any other
plain TCP/IP packet to the network. So ILA is compatible with existing
network functions and optimization's like DPI and parsing packet
capture, ECMP, IPv6 header compression like in 6LoWPAN, checksum
offload, no worries about tunnel MTU, etc.. ILA processing is minimal,
this is just one fixed length lookup on destination address and one
write to it. Performance testing demonstrates ILA is within the noise
of normal non-ILA performance and at least a 10% improvement over any
IP/IP encapsulation technique. Such performance and zero overhead was
actually a hard requirement in developing ILA. In the DC at least,
there is zero tolerance to degrade application performance for the
benefit of a networking infrastructure feature.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Sat, 9 Dec 2017 11:13:56 -0800

On Fri, Dec 8, 2017 at 1:37 PM, Schumacher L. <[email-masked]>
wrote:

> Eventually, this is a regular TCP/IP stack but, as David Lake puts it, the
> issue is "the extreme over-loading of header vs payload".
>
> Thanks for posting this, but it's really confusing as to what it's showing
(no indication of protocol headers). Would it be possible for someone to
providers the headers for GTP from the outer IP header to inner IP header
that shows the most common _deployed_ format of GTP encapsulation (that is
without including optional components that are rarely present)? AFAICT the
simplest necessary encpasulation should be IP|UDP|GTP|IP where the
encapsulation overhead is 56 bytes for IPv6 or 36 for IPv4. Is there really
more overhead than that in practice?

Tom

Best regards,
> LS
> --
>
> Laurent SCHUMACHER
> Professeur
> Faculté d'Informatique
>
> T. +32 (0)81 724 980
> F. +32 (0)81 724 967
> [email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 9 Dec 2017 11:27:04 -0800

Why do I get the feeling the technical details may not be the deciding factor in 3GPP. Am I wrong?

Dino

> On Dec 9, 2017, at 6:46 AM, <[email-masked]> <[email-masked]> wrote:
> 
> <dl> in-line </dl>
>

---

From: <[email-masked]>
Date: Sat, 9 Dec 2017 22:57:57 +0000

Membership of 3GPP is based on organisations and their needs, not individuals as in IETF.

There is plenty of technical discussion at the 3GPP meetings, but remember that the work-plans and the deliverables are planned around defined release dates.

So we're dealing with two organisations with very different DNA.

There is nothing to stop IETF taking a working proposal to 3GPP and presenting that at one of the 3GPP Work Areas but remember that the members of 3GPP are large operators and vendors who will need to ensure interoperability and ease of deployment.  Even if we have a "better" technical solution, operational/commercial concerns will always trump that in 3GPP, especially in this environment of rapidly decreasing revenues for all the operators.

Of course, if you present a technical solution which can be introduced with zero disruption and minimal capital outlay which will (ideally) reverse the revenue decline, I'm sure you'd have 3GPP biting your hand off!

D

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: 09 December 2017 19:27
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Dino

> To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> <dl> I know of one UK operator who run a service for VoIP which roams 
> between WiFI and LTE but the service is being discontinued... </dl>
> 
>>>> in that environment. We also ought to think where mapping server 
>>>> has to be for example and should start with key use cases where a 
>>>>> complexity with 3GPP system using a licensed radio, there is no comparison.
>>>>>

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 9 Dec 2017 16:32:14 -0800

> Even if we have a "better" technical solution, operational/commercial concerns will always trump that in 3GPP, especially in this environment of rapidly decreasing revenues for all the operators.

Than it’s not a better solution. 

> Of course, if you present a technical solution which can be introduced with zero disruption and minimal capital outlay which will (ideally) reverse the revenue decline, I'm sure you'd have 3GPP bit…

Right. Thanks David. 

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Dec 2017 08:57:46 +0100

Le 09/12/2017 à 15:46, [email-masked] a écrit :
> <dl> in-line </dl>
> 
> -----Original Message----- From: Alexandre Petrescu
> [mailto:[email-masked]] Sent: 09 December 2017 12:18 
>> between 802.11 and LTE attach (Trusted and Untrusted Wireless
>> access in 3GPP terms).
> 

WiFi and VoiP: is that with PMIPv4?  INFORMATIONAL RFC5563.

[...]

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Dec 2017 09:04:37 +0100

Le 09/12/2017 à 17:12, Sri Gundavelli (sgundave) a écrit :
> architectures.
> Million’s of CPE’s are running PMIP MAG code and supporting
> Wi-Fi services.

I did not know that.  But I can not help wondering why CPEs need the 
mobile characteristic of PMIP - these CPEs never move, right?

I am not saying this to challenge your view, it is just strange to me. 
And it can stay that strange.

> Applications such as, Service Provider Wi-Fi, Private
> Routing Over LTE,

Private routing over LTE: it sounds a little bit like yet another set of 
layers on that LTE stack.

> Mobile Networks are some of the use-cases based on this

I agree with you Sri, on this paragraph.

I agree many of the IETF protocols are used by 3GPP.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Dec 2017 09:11:17 +0100

Le 09/12/2017 à 20:13, Tom Herbert a écrit :
> 
> 
> On Fri, Dec 8, 2017 at 1:37 PM, Schumacher L. 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Dear Alexandre,
> 
>     Eventually, this is a regular TCP/IP stack but, as David Lake puts
>     it, the issue is "the extreme over-loading of header vs payload".
> 
> Thanks for posting this, but it's really confusing as to what it's 
> showing (no indication of protocol headers).

I agree it is a little bit confusing.

On one hand it shows addresses as if they were in headers, on another 
hand it shows layers.

But I think it could help to show these 11 layers:

User Payload
IPv6 layer [DA, SA]
GRE layer [Tunnel ID]
UDP layer1 [DPort, SPort]
IP layer1 [IP DA, IP SA]
VPN layer2 [VPN label]
MPLS layer2 [LSP label]
802.1q layer [VLAN ID]
MAC layer2 [DMAC, SMAC]
VPN layer1 [VPN label]
MPLS layer1 [LSP label]
MAC layer1 [DMAC, SMAC]

> Would it be possible for 
> someone to providers the headers for GTP from the outer IP header to 
> inner IP header that shows the most common _deployed_ format of GTP 
> encapsulation (that is without including optional components that are 
> rarely present)? AFAICT the simplest necessary encpasulation should be 
> IP|UDP|GTP|IP where the encapsulation overhead is 56 bytes for IPv6 or 
> 36 for IPv4. Is there really more overhead than that in practice?

YEs, I can provide a packet dump of a GTP-U header.

Alex

>     <http://www.unamur.be/universite/personnes/page_view/01005249/>
>     <http://be.linkedin.com/pub/laurent-schumacher/0/32b/7b7>
> 
>     Université de Namur ASBL
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/5gangip>
> 
> 
> 
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 09:13:26 +0100 (CET)

> mobile characteristic of PMIP - these CPEs never move, right?

I'm not saying it's for this reason for this case, but I learnt something 
I didn't know, as I participated in 5G discussions a few years back. It 
wasn't obvious to me, and I can imagine it's not obvious to others as 
well.

When you're participating in "mobile networks", you often have the ability 
to contact multiple base stations. Even if you're stationary, radio 
conditions (of all kinds) might change and the network (or you) might 
decide it's better to hop over to another base station for a while.

So just because you're not moving doesn't mean you don't want to support 
mobile protocols.

Otoh I fully agree with Cameron that most traffic doesn't need this 
mobility, and we should have different network slices for different 
characteristic. Non-live streaming video traffic (that can be 
buffered 5-10 seconds) doesn't need address stability. It can handle its 
task without it.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Dec 2017 09:20:10 +0100

Le 11/12/2017 à 09:13, Mikael Abrahamsson a écrit :
> I'm not saying it's for this reason for this case, but I learnt 
> something I didn't know, as I participated in 5G discussions a few years 
> back. It wasn't obvious to me, and I can imagine it's not obvious to 
> others as well.
> 
> When you're participating in "mobile networks", you often have the 
> ability to contact multiple base stations. Even if you're stationary, 
> radio conditions (of all kinds) might change and the network (or you) 
> might decide it's better to hop over to another base station for a while.
> 

Mikael, where I live the WiMAX-style 3.5GHz CPEs use directional 
antennas pointed to one base-station.  I doubt it connects to multiple 
base stations.

Alex

> characteristic. Non-live streaming video traffic (that can be buffered 
> 5-10 seconds) doesn't need address stability. It can handle its task 
> without it.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Dec 2017 14:25:46 +0100

Le 08/12/2017 à 16:18, Ca By a écrit :
> 
> On Fri, Dec 8, 2017 at 12:38 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     or some

YEs.  But that should be IPv6.

> Disagree. DNSSEC has caused more problems (misconfigurations outages, 
> ddos amplification) than it has solved (had dnssec prevented any real 
> world attack? Really?)

I do not know about DNSSEC.

But I do know that ping6 64:ff9b::8.8.8.8 is likely to not display FQDNs 
in the "received from".  This is from experience with NAT64 at IETF, 
that I may try again at the next IETF.

When ping6 does not display FQDNs, it is a hint that smtp will probably 
have a hard time to distinguish spam by trying the reverse DNS.  That is 
a security aspect not only of DNS, even though DNS is one of the most 
visible.

When ping6 does not work, it is a breakage.  Other than ping6, other 
hints of breakage under NAT64 are: skype does not work on NAT64, and 
other apps too.  It's not because they dont support IPv6, it's because 
they have IPv4 literals built in.

> record for ipv4-only resources is not a huge issue. The obvious fix, if 
> the resource is on any value, is to use ipv6 — problems solved and dns64 
> avoided.

Yes plaintext passwords is a huge security issue.  But I dont think 
DNSSEC uses plaintext passwords?

The signature of records in DNS is one security aspect of DNS.  The 
other is the ability to have meaningful reverse resolution.

> This is a feature, not an flaw.

The two points are debatable.  There are pros and cons.

Alex

>     this? Is
>     models,
>      > <[email-masked] <mailto:[email-masked]> on
>     behalf of [email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>     state the
>     close to
>      >> From: 5gangip [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Uma Chunduri
>      >> To: [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>;
>      >> From: 5gangip [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of
>      >> [email-masked] <mailto:[email-masked]>
>      >> To: [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>      >> That sounds like a detailed plan (and a great bunch of work)!
>     ;-) Do we
>      >> have already volunteers to contribute?
>      >> From: 5gangip [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Alexandre
>      >> Petrescu
>      >> To: [email-masked] <mailto:[email-masked]>
>      >>> *From:*5gangip [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Sri
>      >>> *To:* Ca By <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]> *Cc:*
>      >>> [email-masked] <mailto:[email-masked]>; Bill Gage
>     <[email-masked] <mailto:[email-masked]>>; Satoru Matsushima
>      >>> <[email-masked]
>     <mailto:[email-masked]>>; Tom Herbert
>     <[email-masked] <mailto:[email-masked]>>
>     admit
>     that the
>     of some
>     list

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Dec 2017 07:09:49 -0800

On Dec 11, 2017 12:13 AM, "Mikael Abrahamsson" <[email-masked]> wrote:

I did not know that.  But I can not help wondering why CPEs need the mobile
> characteristic of PMIP - these CPEs never move, right?
>

I'm not saying it's for this reason for this case, but I learnt something I
didn't know, as I participated in 5G discussions a few years back. It
wasn't obvious to me, and I can imagine it's not obvious to others as well.

Otoh I fully agree with Cameron that most traffic doesn't need this
mobility, and we should have different network slices for different
characteristic. Non-live streaming video traffic (that can be buffered 5-10
seconds) doesn't need address stability. It can handle its task without it.

Mikael,

How does the network know what traffic is sensitive to high latency in
mobility and what traffic isn't?

Tom

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 16:21:02 +0100 (CET)

> mobility and what traffic isn't?

That's not up to the network, that's up to the end node. So the 
application decides what traffic should go where.

---

From: <[email-masked]>
Date: Mon, 11 Dec 2017 15:31:21 +0000

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 11 December 2017 15:21
To: Tom Herbert <[email-masked]>
Cc: [email-masked]; Alexandre Petrescu <[email-masked]>
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

> mobility and what traffic isn't?

That's not up to the network, that's up to the end node. So the application decides what traffic should go where.

<dl>  I'm not sure that is entirely correct.  I think it is up to provisioning in the same way that a VoLTE bearer is built today by the user-profile on the HSS.

Otherwise, we're going to have every user and application declaring that "their" traffic is the most important, requires the highest bandwidth, lowest latency, etc.

This is a matter of admission control which is perfectly possible in the current EPC/RAN but only ever implemented for one service, VoLTE.

My guess is that we'll end up with "service slices" - groups of applications and SLAs which your traffic is directed to based on whether your profile subscribes to that service or-not.</dl>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Dec 2017 07:31:59 -0800

On Dec 11, 2017 7:21 AM, "Mikael Abrahamsson" <[email-masked]> wrote:

> mobility and what traffic isn't?

That's not up to the network, that's up to the end node. So the application
decides what traffic should go where.

Then what are interfaces whereby an application signals it's
characteristics to the OS and the OS signals the network about a flow?

Tom

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 16:36:34 +0100 (CET)

> <dl>  I'm not sure that is entirely correct.  I think it is up to provisioning in the same way that a VoLTE bearer is built today by the user-profile on the HSS.

What I stated is my opinion how things should be. You can have a 
different opinion, that's fine. PLease don't use the word "correct" there 
though.

> Otherwise, we're going to have every user and application declaring that 
> "their" traffic is the most important, requires the highest bandwidth, 
> lowest latency, etc.

Of course there would be cost or other limiters involved. The idea here is 
anyway to have lower priority bulk traffic to go a different route than 
the rest. Currently in 3GPP all traffic is sent through the high-touch 
mobile core, for no apparent good reason. Please read Camerons email 
again.

> My guess is that we'll end up with "service slices" - groups of 
> applications and SLAs which your traffic is directed to based on whether 
> your profile subscribes to that service or-not.</dl>

That's exactly what we're talking about.

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Mon, 11 Dec 2017 15:42:37 +0000

On 11/12/2017, 15:32, "5gangip on behalf of Tom Herbert" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Dec 11, 2017 7:21 AM, "Mikael Abrahamsson" <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, 11 Dec 2017, Tom Herbert wrote:
How does the network know what traffic is sensitive to high latency in mobility and what traffic isn't?

Then what are interfaces whereby an application signals it's characteristics to the OS and the OS signals the network about a flow?

LLT https://tools.ietf.org/html/draft-you-tsvwg-latency-loss-tradeoff-00 was a proposal to define that interface.

I’m not completely sure that DSCP is the right tool, but the main merit of LLT is another, it’s to use a one bit signal that doesn’t allow endpoints to cheat.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 16:43:01 +0100 (CET)

> characteristics to the OS and the OS signals the network about a flow?

Perhaps we can invent one?

>From what I can tell there are already proprietary APIs for this on some 
vendors devices.

I can for instance today tell my Youtube app on iOS to use different 
quality (streaming rate) depending on whether I am on wifi or on 3GPP 
interface for my Internet access. I can tell my phone upload app to send 
different resolutions depending on what uplink I have. I can tell my phone 
not to back up data over 3GPP interface at all, or update the applications 
on the device, and only to do that on wifi.

So creating an API to say "application, please tell me if you need 
mobility or not on your flow, and if you're interested in notifications 
when handovers are about to happen and when they're done". As an example. 
Then the application can say "oh, this traffic is streaming video with 10 
second playback buffer, there is no problem to stop the download for 2 
seconds when a handover is done, and after the handover is done, resume 
download of things to go into the playback buffer on the new IP I have in 
the non-mobile-slice".

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 16:43:59 +0100 (CET)

On Mon, 11 Dec 2017, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote:

> I’m not completely sure that DSCP is the right tool, but the main merit 
> of LLT is another, it’s to use a one bit signal that doesn’t allow 
> endpoints to cheat.

I think DSCP would be an awful choice.

This should be done using source address selection and/or interface 
selection (in a MIF (Multiple Interfaces)) context.

---

From: <[email-masked]>
Date: Mon, 11 Dec 2017 15:46:44 +0000

With apologies for use of "correct." No intention to offend.  I'm not that argumentative a person... 😊  Others <dl> in-line </dl>

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: 11 December 2017 15:37
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [5gangip] MINUTES of side meeting in Singapore

> <dl>  I'm not sure that is entirely correct.  I think it is up to provisioning in the same way that a VoLTE bearer is built today by the user-profile on the HSS.

What I stated is my opinion how things should be. You can have a different opinion, that's fine. PLease don't use the word "correct" there though.

> Otherwise, we're going to have every user and application declaring 
> that "their" traffic is the most important, requires the highest 
> bandwidth, lowest latency, etc.

Of course there would be cost or other limiters involved. The idea here is anyway to have lower priority bulk traffic to go a different route than the rest. Currently in 3GPP all traffic is sent through the high-touch mobile core, for no apparent good reason. Please read Camerons email again.

<dl> My point was really about what do you trust.  As far as I can see, the only thing you can trust is the HSS (or 5G equivalent) because that is where you will have paid your money and bought your service.  We then need to translate that paid-for service to traffic classification and packet treatment and I am not sure which interfaces we would use to do that - (N2, N4?) </dl>

> applications and SLAs which your traffic is directed to based on 
> whether your profile subscribes to that service or-not.</dl>

<dl> That is not the current goal of the IETF Network Slicing group - they are looking to be far more granular. </dl>

<dl> Yes, but I think we need to be very careful about what we trust to direct the traffic

---

From: <[email-masked]>
Date: Mon, 11 Dec 2017 15:54:26 +0000

Mikael

Yes you can tell YouTube to use a different streaming rate, but the underlying network in LTE will still use the Default bearer with no guarantee of bandwidth/throughput.

This is contradictory to VoLTE where you WILL use a Dedicated bearer capable of supporting your voice quality.  If the RF network is unable to support this, the network will drop your voice call back to CS.

Now, what I would LIKE to see is the ability for applications external to the mobile network to be able to signal and use the PCRF to deliver a Dedicated Bearer for its specific traffic - for example, you want to watch and HD BBC iPLayer video and the BBC CDN signals the PCRF to ensure that the traffic specific to that session is delivered over a Dedicated Bearer cable of supporting HD video.

Technically, this is possible (we have multiple levels of QCI on LTE but today only use 2) but it has never happened.

That would allow new services to appear where you could pay the OTT for better quality and then settle the cost of providing that quality to the network operator.  Today, the operators just see OTTs as eating their bandwidth and not paying their way.

This is why I said in my earlier email that I think the correct place to classify is where you pay to buy the service.

David

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 11 December 2017 15:43
To: Tom Herbert <[email-masked]>
Cc: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

vendors devices.

I can for instance today tell my Youtube app on iOS to use different quality (streaming rate) depending on whether I am on wifi or on 3GPP interface for my Internet access. I can tell my phone upload app to send different resolutions depending on what uplink I have. I can tell my phone not to back up data over 3GPP interface at all, or update the applications on the device, and only to do that on wifi.

So creating an API to say "application, please tell me if you need mobility or not on your flow, and if you're interested in notifications when handovers are about to happen and when they're done". As an example. 
Then the application can say "oh, this traffic is streaming video with 10 second playback buffer, there is no problem to stop the download for 2 seconds when a handover is done, and after the handover is done, resume download of things to go into the playback buffer on the new IP I have in the non-mobile-slice".

---

From: Ca By <[email-masked]>
Date: Mon, 11 Dec 2017 16:08:04 +0000

On Mon, Dec 11, 2017 at 7:54 AM <[email-masked]> wrote:

> Mikael
>
> Yes you can tell YouTube to use a different streaming rate, but the
> underlying network in LTE will still use the Default bearer with no
> guarantee of bandwidth/throughput.
>
> This is contradictory to VoLTE where you WILL use a Dedicated bearer
> capable of supporting your voice quality.  If the RF network is unable to
> support this, the network will drop your voice call back to CS.
>
> Now, what I would LIKE to see is the ability for applications external to
> the mobile network to be able to signal and use the PCRF to deliver a
> Dedicated Bearer for its specific traffic - for example, you want to watch
> and HD BBC iPLayer video and the BBC CDN signals the PCRF to ensure that
> the traffic specific to that session is delivered over a Dedicated Bearer
> cable of supporting HD video.
>
> Technically, this is possible (we have multiple levels of QCI on LTE but
> today only use 2) but it has never happened.
>
> That would allow new services to appear where you could pay the OTT for
> better quality and then settle the cost of providing that quality to the
> network operator.  Today, the operators just see OTTs as eating their
> bandwidth and not paying their way.
>
> This is why I said in my earlier email that I think the correct place to
> classify is where you pay to buy the service.
>
> David
>

Please bing “3gpp tft” for background on what is already defined

---

From: <[email-masked]>
Date: Mon, 11 Dec 2017 16:19:12 +0000

Cameron

In the real world, how often is a Dedicated Bearer NOT used for VoLTE configured and how often is TFT deployed?

I was told that the majority of devices out there today only support two bearers – default and dedicated for VoLTE - so I’d assumed (maybe incorrectly) that it was not possible to build a 2nd Dedicated Bearer today and prioritise using TFT profiles ?

It would seem that the TFT profile would be quite a nice way of helping us classify traffic though…..

D

From: Ca By [mailto:[email-masked]]
Sent: 11 December 2017 16:08
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

On Mon, Dec 11, 2017 at 7:54 AM <[email-masked]<mailto:[email-masked]>> wrote:
Mikael

David

-----Original Message-----
From: 5gangip [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mikael Abrahamsson
Sent: 11 December 2017 15:43
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

vendors devices.

--
Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>

---

From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Mon, 11 Dec 2017 16:27:50 +0000

On 11/12/2017, 16:19, "5gangip on behalf of [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Cameron

This matches my understanding: one or two years ago in GSMA we asked MNOs if they were using dedicated bearers for Internet traffic and the response was negative.  I don’t know if anything has changed in the meanwhile, but at the time everything Internet-bound seemed to flow through the default bearer.

D

David

-----Original Message-----
From: 5gangip [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mikael Abrahamsson
Sent: 11 December 2017 15:43
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

vendors devices.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Dec 2017 09:02:55 -0800

> Perhaps we can invent one?
This has already been tried in IETF as SPUD, PLUS, maybe a few others.
To date, no serious candidate has been proposed as a generic
application to network signaling protocol. One (of many problems) the
proponents inevitably hit is that commuication is bidirectional, so
path characteristics have to be set for both directions. DSCP is only
relevant in the device TX path, not receive path unless the remote
server reflects TOS. We can do reflection in the DC, but it's not
useful in the Internet. So these efforts fall back to relying on
complex flow stateful semantics in signaling and stateful middleboxes.
Requiring yet more stateful devices in the network, especially for
something that is about L2/L3 properties, is a hard sell in IETF.

Tom

> I can for instance today tell my Youtube app on iOS to use different quality
> (streaming rate) depending on whether I am on wifi or on 3GPP interface for
> my Internet access. I can tell my phone upload app to send different
> resolutions depending on what uplink I have. I can tell my phone not to back
> up data over 3GPP interface at all, or update the applications on the
> device, and only to do that on wifi.
>
> So creating an API to say "application, please tell me if you need mobility
> or not on your flow, and if you're interested in notifications when
> handovers are about to happen and when they're done". As an example. Then
> the application can say "oh, this traffic is streaming video with 10 second
> playback buffer, there is no problem to stop the download for 2 seconds when
> a handover is done, and after the handover is done, resume download of
> things to go into the playback buffer on the new IP I have in the
> non-mobile-slice".
>
>
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 18:40:24 +0100 (CET)

On Mon, 11 Dec 2017, Tom Herbert wrote:

> application to network signaling protocol.

That is not what I was talking about.

The network supplies two different attachment methods. One looks like 
todays 3GPP network with network assisted mobility, bearers etc, the other 
does not. Second is basically like WIFI with no handover and separate 
address space for each AP. Each base station has its own routing space and 
no mobility is offered by the network, this has to be handled by the 
device/application itself.

So as a handover needs to be done for the 
non-network-assisted-handover-space, the operating system on the device 
will tell streaming video applications to stop using the old address-space 
that was based on address space offered by base1 and then gets 
address-space from base2 and offers this to the application.

So the "handover" consists of the following steps to a video-streaming 
application:

1. It fills its 10 second playback buffer, and makes sure it's filled over 
time.
2. device moves and needs to hand over to a new base station (either 
decides this itself or the network tells it to do that). Operating 
system in device tells app to get ready for handover. App stops asking 
for more videodata and closes its connections based on base1 address 
space.
3. new address space is gained from base2. address space from base1 is 
released.
4. application starts requesting data based on addresses from base2.
5. application fills up playback buffer back to 10s worth of data

If the handover takes 4 seconds then the playback buffer will dip down to 
6 seconds worth of "fill".

The user will notice nothing, and no requirement to tunnel this traffic 
exists in the network, and the network doesn't need to assist in doing the 
handover. The device does this itself. It could also do "handover" with 
using LISP, SHIM6, MP-TCP or similar mechanism. The device itself is 
handling the mobility.

The API needed doesn't need to talk to the network, it just needs to 
choose the correct source address.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Dec 2017 10:05:22 -0800

On Mon, Dec 11, 2017 at 9:40 AM, Mikael Abrahamsson <[email-masked]> wrote:
> The network supplies two different attachment methods. One looks like todays
> 3GPP network with network assisted mobility, bearers etc, the other does
> not. Second is basically like WIFI with no handover and separate address
> space for each AP. Each base station has its own routing space and no
> mobility is offered by the network, this has to be handled by the
> non-network-assisted-handover-space, the operating system on the device will
> tell streaming video applications to stop using the old address-space that
> was based on address space offered by base1 and then gets address-space from
> base2 and offers this to the application.
>
> 2. device moves and needs to hand over to a new base station (either decides
> this itself or the network tells it to do that). Operating system in device
> tells app to get ready for handover. App stops asking for more videodata and
> closes its connections based on base1 address space.
> If the handover takes 4 seconds then the playback buffer will dip down to 6
> seconds worth of "fill".
>
> The API needed doesn't need to talk to the network, it just needs to choose
> the correct source address.
>
I think your proposing that the source address encodes service characteristics.

Sure, the application can selectively bind to a source address. But
then how does it know that different source addresses imply different
semantics? What API does the application use to get the necessary
information? And even if it did know the difference, what's its
motivation to the choose the "correct" one. Why wouldn't an
application just always choose the one with lowest latency and best
service?

Tom

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 19:14:22 +0100 (CET)

> I think your proposing that the source address encodes service characteristics.

Yes, or rather that certain interfaces on the device encodes service 
characteristics. Each interface might have one or more addresses.

> Sure, the application can selectively bind to a source address. But then 
> how does it know that different source addresses imply different 
> motivation to the choose the "correct" one. Why wouldn't an application 
> just always choose the one with lowest latency and best service?

Because I have configured the operating system to only allow this 
application access to this specific characteristic network access. Or it 
came default out of the box that way.

Have you used an modern Apple/Android device lately? They seem to be 
really good at choosing sensible defaults that just work. They already 
have lots of this logic, but they do it between implied characteristics 
because of media access (wifi=cheap, 3GPP=expensive) together with user 
settings.

I have seen settings for "metered yes/no" for both wifi and 3GPP network 
interfaces, so the device operating system can apply sensible defaults.

The problems you're pointing out is being solved as we speak, because 
they're problems now, not only in the future.

The motivation for the apps to do the right thing is because otherwise 
people won't use the damn app, because it cost them money or the device 
manufacturer will remove that app from the app store for violations of the 
rules.

---

From: <[email-masked]>
Date: Mon, 11 Dec 2017 18:28:12 +0000

Mikael

This:

“because of media access (wifi=cheap, 3GPP=expensive) “

I disagree with.   Wi-fi is non-performant and expensive in many cases as cellular trends to utility levels and prices.

I rarely use WiFi any more when travelling because it costs so much (hotel yesterday in Madrid €19/day - more than I pay a month for “unlimited” LTE across the EU and roaming in the US).

Also I get excellent voice quality on   VoLTE where LTE coverage is good - I cannot say the same about shared WiFi especially where it contends for my slow DSL line (76Mbit/s).

Matter of opinion, of course, but certainly in the last 3-4 years, LTE is everywhere I need it to be with no WiFi Association/logins...

David

Sent from my iPhone
________________________________
From: 5gangip <[email-masked]> on behalf of Mikael Abrahamsson <[email-masked]>
Sent: Monday, December 11, 2017 7:14:22 PM
To: Tom Herbert
Cc: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

---

From: Tom Herbert <[email-masked]>
Date: Mon, 11 Dec 2017 10:32:05 -0800

On Mon, Dec 11, 2017 at 10:14 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> how does it know that different source addresses imply different semantics?
>> What API does the application use to get the necessary information? And even
>> if it did know the difference, what's its motivation to the choose the
>> "correct" one. Why wouldn't an application just always choose the one with
>> lowest latency and best service?
>
>
> Have you used an modern Apple/Android device lately? They seem to be really
> good at choosing sensible defaults that just work. They already have lots of
> this logic, but they do it between implied characteristics because of media
> access (wifi=cheap, 3GPP=expensive) together with user settings.
>
Rules, user configuration, per app settings? What you are descrbing
sounds incredibly complex. IMO, if mobility is solved genericially as
a layer 3 problem of mobility that is transparent to applications,
transport protocols, and the users. No need to create new APIs, no
need to have per application behaviors, no need to rewrite
applications, no need to upgrade OS. Seems so much simpler to assume
everything is mobile and build the infrastructure around that
assumption...

Tom

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 19:39:33 +0100 (CET)

> I disagree with.   Wi-fi is non-performant and expensive in many cases as cellular trends to utility levels and prices.

You can disagree all you want, this is just the way it's done right now.

I have unlimited multihundra-megabit/s access using wifi with fixed access 
in my home for less than 40EUR a month. The unlimited LTE access is 60EUR 
a month *per device*, and comes with a bunch of limitations.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 19:44:00 +0100 (CET)

On Mon, 11 Dec 2017, Tom Herbert wrote:

> sounds incredibly complex. IMO, if mobility is solved genericially as a 
> layer 3 problem of mobility that is transparent to applications, 
> transport protocols, and the users. No need to create new APIs, no need 
> to have per application behaviors, no need to rewrite applications, no 
> need to upgrade OS. Seems so much simpler to assume everything is mobile 
> and build the infrastructure around that assumption...

My take is that 5G is going to be LTE with some extra sauce added to it. 
It will not be simpler than LTE (which is extremely complex), because most 
people seem to want to keep all the complication in there. Most of the 
hype and promises in the marketing will not be fulfilled.

So I'm going to go back to sleep, I am pretty tired of having these 
discussions with people who keep bringing up bearers, PCRFs and all the 
other extremely complex mechanisms in 3GPP networks that basically nobody 
uses because most traffic is just done in the best-effort bearer and the 
whole VoLTE fiasco took 5+ years to implement for most carriers because of 
all the added complexity to do it.

---

From: <[email-masked]>
Date: Mon, 11 Dec 2017 18:48:19 +0000

Yes - it varies by region/country.

The most expensive LTE service we have is £15/month for 20GB unlimited voice/text. In the same way younger generations never have a fixed phone line, increasing numbers are just relying on an LTE service for broadband.

Now you could argue whether the operators can afford to invest in 5G if the revenues are that low, but that is economics, not engineering...

So for me, WiFi makes no sense as even at 5GHz I can see so many other networks at home that performance suffers.

The solution we build needs to understand (and use to best advantage) both of our experiences.

D

Sent from my iPhone
________________________________
From: Mikael Abrahamsson <[email-masked]>
Sent: Monday, December 11, 2017 7:39:33 PM
To: Lake D Mr (PG/R - Elec Electronic Eng)
Cc: [email-masked]; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 19:50:45 +0100 (CET)

On Mon, 11 Dec 2017, [email-masked] wrote:

> The most expensive LTE service we have is £15/month for 20GB unlimited voice/text.

My household does 500 gigabytes per month of data. Most of this streaming 
video.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 20:01:37 +0100 (CET)

> The solution we build needs to understand (and use to best advantage) 

Your usecase (if you can make do with 20GB of data per month) seems to be 
already solved by LTE. My use-case (terabytes/month) seems not, because 
LTE is too expensive due to its complexity, to produce this service. 
You're goint to need an extremely dense radio network to address this, 
meaning low complexity base stations with low IPR costs per base.

People don't want to bother with 3GPP or Wifi, they just want "always-on 
Internet access in all devices". So if 5G doesn't solve this completely 
"eat" the market/price position that "fixed access+wifi" has today, then 
5G is a complete failure in my book. Wifi has one thing going for it, and 
that's low cost. It can be included into devices at very low cost compared 
to most 3GPP radios.

So, come up with something that allows a "5G" device to connect anywhere, 
and we have a winner. 5G in this case in all devices, not that "it's too 
expensive so we're just going to include a wifi radio, no 3GPP radio".

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 11 Dec 2017 19:19:28 +0000

>So I'm going to go back to sleep, I am pretty tired of having these discussions with people who keep bringing up bearers, PCRFs and all the other extremely complex mechanisms in 3GPP networks that basically nobody uses because most traffic is just done in the best-effort bearer and the whole VoLTE fiasco took 5+ years to implement for most carriers because of all the added complexity to do it.

Agreed and OTT voice/video/instant messaging works pretty damn well world-wide on every network interface and their mobility solution works over every access technology too, although it's disruptive most of the time since my end IP address changes but my actual ID never has to change. QOS could of course be improved on selective links.

In my mind the idea of using ID-location separated routing is simply stealing the method that OTT/s and VPNs , vxlan etc. already use and incorporating it into 5G while replacing all that complex competing infrastructure that you point out is underused but still has to  be developed, tested and paid for.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 11 Dec 2017 20:33:18 +0100 (CET)

On Mon, 11 Dec 2017, AshwoodsmithPeter wrote:

> In my mind the idea of using ID-location separated routing is simply 
> stealing the method that OTT/s and VPNs , vxlan etc. already use and 
> incorporating it into 5G while replacing all that complex competing 
> infrastructure that you point out is underused but still has to be 
> developed, tested and paid for.

I don't understand anything you just wrote here. Please rephrase.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 11 Dec 2017 20:27:48 +0000

Mikael, sorry ... let me try again:

If we consider generically any system where:

    Packets have: [OUTER] [ INNER] [ PAYLOAD]    and where:
    Packets are routed only on OUTER through a core and mapped to INNER at the edges
    and a mapping system that keeps < INNER, OUTER > relationships and is only available at the edges.

MPLS VPN's use labels for INNER and OUTER and often BGP for mapping.
VXLAN uses IP for OUTER and Ethernet for INNER and various options for mapping.
OTT voice/video uses your user-id as INNER and IP as OUTER and likely a DHT for mapping.

All the ID-LOC variations have therefore similar architectures to the above and therefore are not completely different concepts and much can be learned/explained/taught from that architectural concept before the differences in a specific implementation become important.

For example if you are trying to convince somebody that ID-LOC separation is a good way to deal with fixed mobile convergence you don't need to look much at formats, it's the concept that gets you the convergence. If FMC is an important issue you only need to get agreement on the concept not the implementation which is an easier debate to win.

Peter

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Dec 2017 08:41:33 +0100 (CET)

> OTT voice/video uses your user-id as INNER and IP as OUTER and likely a DHT for mapping.

I don't think what you're saying above describes what I proposed.

I proposed that each UE (for some of its traffic, such as video streaming) 
handled its own "mobility". As in "close TCP session on old IPv6 address, 
open new TCP session on new address" or in case the application layer can 
handle multiple endpoints for the same connection (such as MP-TCP) then 
that this layer handles that. Not that there is "routing" to handle it.

There is no "outer" or "inner" here, unless you count "ID" as being in the 
application layer (such as a cryptographic cookie or similar), then I 
guess that could count as "inner". It's not something the network has to 
know about, regardless.

This means the network doesn't have to know anything about mobility for 
this traffic. UE and its OS/app handle this on their own (just like they 
do today when I watch youtube and move from 3GPP to wifi and it then 
seamlessly starts pulling data from wifi instead of 3GPP radio after wifi 
is deemed working).

This means there is no re-routing or encapsulation or tunnels that the 
network has to do, for 90% of the traffic (or more). It's just regular 
"routing", as it was in the 90ties with just regular IGP (with BGP if one 
prefers).

My assumption is that traffic growth will come from more and more video 
over time, as it already is with all the video streaming OTTs.

---

From: Ca By <[email-masked]>
Date: Tue, 12 Dec 2017 15:33:44 +0000

> over time, as it already is with all the video streaming OTTs.

Mikael — yes !

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 12 Dec 2017 16:14:24 +0000

>I proposed that each UE (for some of its traffic, such as video streaming) handled its own "mobility". As in "close TCP session on >old IPv6 address, open new TCP session on new address" or in case the application layer can handle multiple endpoints for the >same connection (such as MP-TCP) then that this layer handles that. Not that there is "routing" to handle it.

Hey Michael, my last one " OTT with a user-id as INNER and IP as outer with DHT for mapping" is I suspect what you are describing. The mobility is done by seamlessly dealing with changes in IP host address by keeping the user-id associated with the current host ip address through a mapping system. There are many different id's that can be used here but they are all above layer 3.  The downside is that there can be lengthy interruptions which while not a problem for heavily buffered video are a problem for voice, interactive video,  real time critical things. 

My general point is that this approach is widely deployed already, so we know it works in the OTT context, and the VPN context and that can perhaps lend weight to it being used in a wireless context.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Dec 2017 17:45:27 +0100 (CET)

On Tue, 12 Dec 2017, AshwoodsmithPeter wrote:

> Hey Michael, my last one " OTT with a user-id as INNER and IP as outer 
> with DHT for mapping" is I suspect what you are describing. The mobility 
> is done by seamlessly dealing with changes in IP host address by keeping 
> the user-id associated with the current host ip address through a 
> mapping system. There are many different id's that can be used here but 
> they are all above layer 3.  The downside is that there can be lengthy 
> interruptions which while not a problem for heavily buffered video are a 
> problem for voice, interactive video, real time critical things.

Right.

This of course should not be used for things that need fast-handovers and 
stable IP endpoints (as I have previously said several times). That kind 
of traffic probably needs network "help" of some kind, just like 3GPP 
networks are designed today.

My point is that having encap/mobility enabled for all traffic means we 
have to process this traffic in ways that is no added benefit to that 
traffic. VOD doesn't need stable endpoints and it's the bulk of traffic, 
so why not simplify its network access?

I could even see that traffic requiring mobility assistance is macro-cell 
only, if that helps wifi/3gpp network convergence and avoids paying IPR 
for media streaming devices that today only has wifi interface.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Dec 2017 08:55:22 -0800

On Tue, Dec 12, 2017 at 8:45 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> with DHT for mapping" is I suspect what you are describing. The mobility is
>> done by seamlessly dealing with changes in IP host address by keeping the
>> user-id associated with the current host ip address through a mapping
>> system. There are many different id's that can be used here but they are all
>> above layer 3.  The downside is that there can be lengthy interruptions
>> which while not a problem for heavily buffered video are a problem for
>> voice, interactive video, real time critical things.
>
>
> Right.
>
> stable IP endpoints (as I have previously said several times). That kind of
> traffic probably needs network "help" of some kind, just like 3GPP networks
> are designed today.
>
Are you going to be charging a premium for the this "help" then?

> My point is that having encap/mobility enabled for all traffic means we have
> to process this traffic in ways that is no added benefit to that traffic.
> VOD doesn't need stable endpoints and it's the bulk of traffic, so why not
> simplify its network access?
>
> only, if that helps wifi/3gpp network convergence and avoids paying IPR for
> media streaming devices that today only has wifi interface.
>
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Dec 2017 18:10:42 +0100 (CET)

> Are you going to be charging a premium for the this "help" then?

That's typically how these things pan out, yes.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 12 Dec 2017 17:25:34 +0000

>My point is that having encap/mobility enabled for all traffic means we have to process this traffic in ways that is no added benefit to that traffic. VOD doesn't need stable endpoints and it's the bulk of traffic, so why not simplify its network access?

Hey Michael,

Yours is not an uncommon view and In fact several years ago many of the wireless customers I visited said similar things. I.e. why do we have this complex infrastructure when most of the time most devices don't move. In fact when slicing was first proposed, "no mobility" for some devices was given as one of the arguments in favor of differentiated slices (along with delay, throughput, reliability etc. attribute differentiation).

There are I believe two challenges with this argument:

1  - a mobile device that does not physically move is still going to experience changes in the cell it attaches to due to RF condition changes and those of course can be quite frequent / oscillatory and could affect many devices at the same time.

2- It would be possible to have a device allocated a new IP address each time it hits a different NB but I suspect this actually involves more messaging since it has to effect state in the PGW (furthest from edge) while mobility can often be done in the SGW (closer to edge) only.

Regards,

Peter

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Dec 2017 09:35:46 -0800

> Yours is not an uncommon view and In fact several years ago many of the wireless customers I visited said similar things. I.e. why do we have this complex infrastructure when most of the time most…

Because you want to multi-home the device without having to change addresses for each attachment point. And in the presences of IPv4 NATs, which WE DO HAVE TO LIVE with, the attachment point address will keep changing. This creates a lack of robustness for applications. Then the apps need to worrry about this network level issue.

Locator/ID separation solves more than just a movement problem.

Dino

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 12 Dec 2017 18:47:25 +0000

Hey Dino, Yes, I should have mentioned that, there is also another twist on this which is a wireless mode where multiple cells transmit and receive from a UE at the same time to effectively increase throughput, range etc. "COMP". In this case of course they want a single address since "part" of any given bit in a packet come from one cell and part from another.

Peter

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Tuesday, December 12, 2017 12:36 PM
To: AshwoodsmithPeter <[email-masked]>
Cc: Mikael Abrahamsson <[email-masked]>; [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

Dino

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Dec 2017 19:48:52 +0100 (CET)

On Tue, 12 Dec 2017, AshwoodsmithPeter wrote:

> 2- It would be possible to have a device allocated a new IP address each 
> time it hits a different NB but I suspect this actually involves more 
> messaging since it has to effect state in the PGW (furthest from edge) 
> while mobility can often be done in the SGW (closer to edge) only.

You're missing the point. You seem to take for granted that most of the 
3GPP dataplane complexity is still involved in what I am proposing. It's 
not. Neither is a lot of the control plane complexity.

The traffic I am talking about isn't tunneled to PGW, or even sent through 
PGW. It isn't sent through SGW either. It's never tunneled to any mobile 
core, at all.

It's just plain IP routed out somewhere close to the base station, as any 
Internet traffic. The base station itself can send router advertisements 
and do the routing. It's basically a "router with wifi", if that makes it 
easier to understand. Think of it more in the context of a wifi AP+router 
with WPA enterprise admission control.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Dec 2017 11:09:15 -0800

Mikael, how you going to aggreagate addresses for route scaling? EnodeB’s will have a prefix block and DCHP-PD to UEs?

Dino

> On Dec 12, 2017, at 10:48 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> You're missing the point. You seem to take for granted that most of the 3GPP dataplane complexity is still involved in what I am proposing. It's not. Neither is a lot of the control plane complexity.
> 
> The traffic I am talking about isn't tunneled to PGW, or even sent through PGW. It isn't sent through SGW either. It's never tunneled to any mobile core, at all.
> 
> It's just plain IP routed out somewhere close to the base station, as any Internet traffic. The base station itself can send router advertisements and do the routing. It's basically a "router with wifi", if that makes it easier to understand. Think of it more in the context of a wifi AP+router with WPA enterprise admission control.
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Dec 2017 20:21:59 +0100 (CET)

On Tue, 12 Dec 2017, Dino Farinacci wrote:

> Mikael, how you going to aggreagate addresses for route scaling? 
> EnodeB’s will have a prefix block and DCHP-PD to UEs?

Yes, or PD or RA /64 per UE, or some other scheme of handing out address 
block.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Dec 2017 11:30:19 -0800

On Tue, Dec 12, 2017 at 10:48 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> messaging since it has to effect state in the PGW (furthest from edge) while
>> mobility can often be done in the SGW (closer to edge) only.
>
>
> You're missing the point. You seem to take for granted that most of the 3GPP
> dataplane complexity is still involved in what I am proposing. It's not.
> Neither is a lot of the control plane complexity.
>
I'm missing your point. You said that this solution applies to 90% of
the traffic. What about the other 10%? Don't they need a mobile
infrastructure in the network for that traffic still? What happens in
time if that 10% grows to 20, 30, 40%...

Besides that, even if you were to reduce complexity in the network,
this would substantially increases complexity higher up the stack as
well as imposing new requirements on applications to now deal with
network layer mobility.

> Internet traffic. The base station itself can send router advertisements and
> do the routing. It's basically a "router with wifi", if that makes it easier
> to understand. Think of it more in the context of a wifi AP+router with WPA
> enterprise admission control.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Dec 2017 20:42:00 +0100 (CET)

> time if that 10% grows to 20, 30, 40%...

I have already stated that the 10% (or whatever it is), needs network 
assistance in its mobility, at least initially. I have also stated that 
streaming video is the overwhelming part of video, and it doesn't have 
fast-mobility requirements.

So what's your idea of what this increasing chunk of total traffic 
that is non-VOD?

My guess is instead that UE handling its own mobility will grow over time 
as more and more mechanisms using this method are developed, instead of 
letting the network be greatly involved here.

A UE can fast-attach in milliseconds and get address space and start 
communicating. It basically needs a single RA (or equivalent) to get /64, 
then it can start communicating. I said seconds before, but that's 
extremely conservative.

> well as imposing new requirements on applications to now deal with

I have already pointed out that this is already happening. I also have 
full faith in the mobile device manufacturers to abstract away this 
complexity for the application programmers. They have shown great ability 
in this so far.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Dec 2017 11:53:03 -0800

And what happens when I want to roam to another provider? I have to reset all my transport connections?

Dino

> On Dec 12, 2017, at 11:21 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> Yes, or PD or RA /64 per UE, or some other scheme of handing out address block.
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Dec 2017 21:28:08 +0100 (CET)

> reset all my transport connections?

You have to do that if you want to roam to the next base station, so yes.

All the transport connections tied to this non-mobility slice, yes. If you 
want mobility for certain traffic, then you have all the capability that 
current 3GPP networks already have (or whatever we invent).

The UE can run a LISP client and tunnel that traffic somewhere, that's 
fine. So the transports that require stable endpoint address, they'd have 
to be tunneled by SOMEONE.

Just because some of the traffic has certain requirements, doesn't mean we 
have to design a network around all traffic getting the same treatment.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Dec 2017 12:39:38 -0800

On Tue, Dec 12, 2017 at 11:42 AM, Mikael Abrahamsson <[email-masked]> wrote:
> So what's your idea of what this increasing chunk of total traffic that is
> non-VOD?
>
Live streaming, interactive chat (e.g. WebEx), gaming, IoT, Smart
Cities, industrial automation, vehicular applications, robotics, AR,
VR...

> My guess is instead that UE handling its own mobility will grow over time as
> more and more mechanisms using this method are developed, instead of letting
> the network be greatly involved here.
>
> then it can start communicating. I said seconds before, but that's extremely
> conservative.

You are only considering the network layer. Not what it takes to
reestablish productive application layer connectivity.

The order of events might be something like this: First the address
needs to be removed from the kernel and connections using that address
are forcibly closed (any outstanding data to send is lost). Then each
application must be woken up, detect the connection dropped, and then
try connection again This is round trips for TCP negotiation, round
trips for TLS negotation, and then work to figure out how to recover
from a recent checkpoint if there is one. Multiply this all by N which
is the number of connections for the device (or downstream devices)
which leads to the stampeding herd problem then you start to get a
picture of what is involved.

If you provide mobility at network layer so that address moves
seamlessly, then the worse case scerario is that application seems a
tiny latency blip or sees a few drop packets that are easy to recover
from.

> I have already pointed out that this is already happening. I also have full
> faith in the mobile device manufacturers to abstract away this complexity
> for the application programmers. They have shown great ability in this so
> far.

Why would this be a problem just for mobile device manufactures? Not
everything thing connected to a mobile network is a "mobile device".
This would be a problem for any device that can connect to WIFI which
in turn connect to a router into a mobile network (e.g. such a person
using a laptop on train WIFI). I think you're implying that the OS
providers need to take the action. Besides that, if the servers get
involved, for instance of you want MP-TCP, then they need to change.
Unless the OS can _completely_ hide the mobility handling, then the
application needs change. So basically, there's a good chance that
you'll require _everything_ to change above the network layer to
support your concept of mobility. In IETF circles this is called
"boiling the ocean".

One relevant datapoint is that seamless/low latency  mobility is
already a solved problem. It works perfectly well for cloud. VM
migration is seamless, doesn't break connections, and doesn't require
applications to changes. If Google were to tell their customers that
they need restart connections everytime one of their VMs migrate then
they'd be losing customers left and right.

Tom

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 12 Dec 2017 20:42:51 +0000

Michael couple of points to consider:

1- The spectrum used by LTE etc. is infinitely better than the crap used by Wifi. It propagates miles and miles while the Wifi spectrum will be absorbed by water molecules etc. and won't go very far. As a result the LTE spectrum costs billions and so its use must be coordinated carefully and its costs recouped by essentially billing/policing each connection against its subscription/plan.  That would need to be designed in to any competing solution. Today it's done at the gateways hence you don't have to aggregate all the NB info and don't have to distribute policy.
Personally I like the idea of moving that into the UE's TEE but nobody else seems to be talking about that as a possible option. 

2 - we can use multiple NB's to co-ordinate transmissions to UE's to increase throughput/range and reduce errors. So an address block per NB won't work in that case. You need to feed all possibly coordinating NB's back to a common point covering a much larger footprint.

3 - there are some interesting issues around paging, i.e. waking up a phone that is in a low power mode when a call arrives otherwise your battery won't last long, where do you send it? Who buffers it etc.

4 - Lawful interception is legally required in pretty much every country for cellular ( assume it's a condition of the spectrum or access), so a solution for that would be required.

Peter

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, December 12, 2017 1:49 PM
To: AshwoodsmithPeter <[email-masked]>
Cc: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

On Tue, 12 Dec 2017, AshwoodsmithPeter wrote:

> 2- It would be possible to have a device allocated a new IP address 
> each time it hits a different NB but I suspect this actually involves 
> more messaging since it has to effect state in the PGW (furthest from 
> edge) while mobility can often be done in the SGW (closer to edge) only.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Dec 2017 12:46:07 -0800

> You have to do that if you want to roam to the next base station, so yes.

This is the problem we (this list) believe is worth solving.

> All the transport connections tied to this non-mobility slice, yes. If you want mobility for certain traffic, then you have all the capability that current 3GPP networks already have (or whatever we invent).

Not when I roam to WiFi. When I said “another provider” I mean “any provider”.

> The UE can run a LISP client and tunnel that traffic somewhere, that's fine. So the transports that require stable endpoint address, they'd have to be tunneled by SOMEONE.

We don’t want to tunnel over the RAN but could locator translate on the UE.

> Just because some of the traffic has certain requirements, doesn't mean we have to design a network around all traffic getting the same treatment.

But you have multiple mechanisms which increases OpEx. And you are not going to stop anyone from tunneling. It may be a second class citizen but its here to stay and we use it everyday for all kinds of reasons.

Dino

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 12 Dec 2017 21:46:59 +0100 (CET)

> Cities, industrial automation, vehicular applications, robotics, AR,

I think 4k VOD will win this race. AR and VR will have latency 
requirements that you basically can't be multiple hops away anyway.

> tiny latency blip or sees a few drop packets that are easy to recover

What you described above is not where the applications are headed. It 
describes where they were. Look at QUIC as an example. Look at what "mosh" 
does for ssh. How much have you talked with people working with networking 
in Apple iOS and Android? Perhaps we should get them more involved in this 
discussion, because they would be better suited to answer their view than 
you and I are. I have spoken to them, I imagine they'd give a different 
answer than you do.

> everything thing connected to a mobile network is a "mobile device".

No, but iOS and Android are eating a lot of the "small device" cake, even 
for stationary devices.

> support your concept of mobility. In IETF circles this is called

Again, you seem to have missed what has happened in the mobile space 
lately (in the past 5 years or so). Since mobile devices regularily do 
what I propose between 3GPP radio and Wifi, this is already happening.

---

From: <[email-masked]>
Date: Tue, 12 Dec 2017 21:15:03 +0000

Peter

<dl> In-line </dl>

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: 12 December 2017 20:43
To: Mikael Abrahamsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

<dl> Exactly.  WiFi is very limited bandwidth and highly contented for.  There is nothing from stopping me from putting any number of WiFi APs into a geographic area, saturating it and causing massive service impact.   That is already happening in most towns and cities at 2.4GHz and starting to happen at 5GHz.

Spectrum co-ordination including legal action against those stealing spectrum they do not have the right to use in LTE ensures that an SLA can be a) written and b) charged for.   That means that we can do things over LTE (guarantees of service levels, pre-emption) which we cannot do in WiFi and we have regulatory teeth (in the UK, this is part of the Department for Culture, Media and Sport who essentially police the spectrum when operators have paid vast sums of money for).   People do go to court and gaol for this.

Much of the 3GPP network is designed to police and manage the spectrum, provide different grades of service.   Without this structure in place, how do you offer an SLA and make money from the end-users? 

This is no different from DSL/fibre services - much of the infrastructure is associated with ensuring that customers get the service they are entitled to and have paid for.  </dl>

<dl> Violent agreement here again.  I'm starting to see large CoMP deployments where the only way of handling this it to make the entire eNB estate appear as a single node (multiple RRHs) with a central BBU.</dl>

<dl> I am aware of one national operator who takes the view that even the presence of tap should not cause a change in network traffic visible to anyone who doesn't hold clearance to know about the existence of the tap.  Therefore, they ONLY tap on SGi in a secure facility which only cleared staff (a handful of people) have access to.

The benefit is that the network traffic flows stay static - if you were to mirror flows and the flow followed a particular IMSI attach/re-attach, then anyone with a network view could be able to put two-and-two together as IMSIs appeared on different eNBs and determine that the person was likely being viewed.  That was seen as a security risk because the vast majority of the network ops staff are not security cleared (SC cleared staff = expensive; non-SC less so).

I am aware of another operator who runs a constant junk bit-stream from every eNB back to the tap point for exactly this purpose as well - if a tap is placed on a user, the junk is replaced with real data.  To NetOps staff, whether there is a tap in place or not is invisible.</dl>

Peter

---

From: Tom Herbert <[email-masked]>
Date: Tue, 12 Dec 2017 19:21:28 -0800

On Tue, Dec 12, 2017 at 12:46 PM, Mikael Abrahamsson <[email-masked]> wrote:
> I think 4k VOD will win this race. AR and VR will have latency requirements
> that you basically can't be multiple hops away anyway.
>
>>> as
>>> extremely
> in Apple iOS and Android?

Quite a bit actually considering I ran the nost networking team at
Google for seven years. My experience is that myopia on just a few
select applications and transport protocols is exactly what led to an
ossified Internet. IMO, proposals that require every host and
application on the Internet to change are pipe dreams. I believe we
are far better off by making a change at one layer that can benefit
_any_ application, _any_ OS, _any_ device, _any_ transport protocol,
_any_ user-- whether yesterday, today, or tomorrow. This is what
identifier/locator split gives for mobility.

Tom

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Dec 2017 09:14:30 +0100 (CET)

> application on the Internet to change are pipe dreams. I believe we

Considering applications today have to deal with moving from wifi to 3GPP 
radio and back to wifi again as a regular many-times-per-day event, this 
is not a new requirement.

> identifier/locator split gives for mobility.

This can be the mobility part for the 10%. I don't care what it looks 
like. Go ahead, come up with whatever is best. I just think it's an 
enormous complication not needed for the bulk of the traffic. If you can 
produce it cheaply enough, then nobody will bother to run the traffic in 
the mode I proposed. Call it "local breakout mode" and offer no mobility. 
What's the harm? Let the application/operating system designers decide 
what to use. The market will figure it out.

With your (and other vocal people in here) thinking, 5G will just be LTE 
with new radio. If we bring in all the old requirements then why not just 
keep things the way they are?

I want 5G to kill "wifi", so I can get "5G"-radios in everything, because 
it'll be cheap and in all devices.

With your thinking, this is not going to happen.

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 13 Dec 2017 08:50:53 +0000

On 13 Dec 2017, at 03:21, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

I believe we

+1

Cheers,
--/Saleem

---

From: Ca By <[email-masked]>
Date: Wed, 13 Dec 2017 13:58:25 +0000

On Wed, Dec 13, 2017 at 12:51 AM Saleem Bhatti <[email-masked]>
wrote:

>
>
> On 13 Dec 2017, at 03:21, Tom Herbert <[email-masked]> wrote:
>
> I believe we

-1 , there are no panaceas, and invoking Deering.
https://www.iab.org/wp-content/IAB-uploads/2011/03/hourglass-london-ietf.pdf

Also, there is no economic incentive for id/loc split (i am phrasing it
this way as a conversation starter). Any economic model you propose must be
back tested against the past 20 years of ipv6 where ipv6 had the advatange
of a cliff (real rir run out, secondary markets)

There is an economic insentive for 3gpp operators to minimize the amount of
traffic carried in the traditional network, and transfer the onus of fine
grain session management and mobility to the app / os

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Dec 2017 15:36:03 +0100

Le 13/12/2017 à 14:58, Ca By a écrit :
> 
> On Wed, Dec 13, 2017 at 12:51 AM Saleem Bhatti <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
> this way as a conversation starter). Any economic model you propose must 
> be back tested against the past 20 years of ipv6 where ipv6 had the 
> advatange of a cliff (real rir run out, secondary markets)
> 
> There is an economic insentive for 3gpp operators to minimize the amount 
> of traffic carried in the traditional network, and transfer the onus of 
> fine grain session management and mobility to the app / os

Let me then speculate on a technical incentive.

NAT64 has problems: using reverse DNS while under NAT64 gives fake results.

DNS is a mapping system.  Maybe concepts from id-loc mapping system can 
help fix the DNS part of NAT64.

Alex

---

From: Ca By <[email-masked]>
Date: Wed, 13 Dec 2017 17:03:48 +0000

> NAT64 has problems: using reverse DNS while under NAT64 gives fake results.

For me as a network operator, i do not consider this a problems.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 Dec 2017 09:09:33 -0800

On Wed, Dec 13, 2017 at 5:58 AM, Ca By <[email-masked]> wrote:
> Also, there is no economic incentive for id/loc split (i am phrasing it this
> way as a conversation starter).

As a general statement this is wrong. id/loc split is already deployed
by every cloud provider via network virtualization at very large
scale. Seamless mobility is provide by live VM migration which is
completely transparent to the applications. Cloud providers have no
incentive to create a tiered mobility model; it's far simpler,
cheaper, more efficient, and easier to manage just one infrastructure.
There is no concept where the cloud provider tells a customer they
need handle VM migration in their apps. And good luck trying tell an
enterprise customer that they need register, disclose, or restrict
their proprieatary applications they want to run on your network--
you'll be watching as they laugh their way out the door to your
competition.

Tom

---

From: Ca By <[email-masked]>
Date: Wed, 13 Dec 2017 17:21:24 +0000

On Wed, Dec 13, 2017 at 9:09 AM Tom Herbert <[email-masked]> wrote:

> this

Ok, thanks for that response to a specific question about the economc
motivation for loc/id in mobile.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 Dec 2017 10:07:12 -0800

> motivation for loc/id in mobile.
Look again. I responded to your statement that you specifically
phrased for conversation. You didn't say this was just applied to
mobile.

"Also, there is no economic incentive for id/loc split (i am phrasing
it this way as a conversation starter)."

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 13 Dec 2017 10:25:28 -0800

> Also, there is no economic incentive for id/loc split (i am phrasing it this way as a conversation starter). Any economic model you propose must be back tested against the past 20 years of ipv6 where ipv6 had the advatange of a cliff (real rir run out, secondary markets)

There is no economic incentive for BGP either.

+1 to Tom.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 13 Dec 2017 10:27:40 -0800

> Ok, thanks for that response to a specific question about the economc motivation for loc/id in mobile. 

Sorry, wrong again. It is already deployed. The loc/id solution for IPv4 is called NAT.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 Dec 2017 10:38:04 -0800

> Sorry, wrong again. It is already deployed. The loc/id solution for IPv4 is called NAT.
True. NAT also highlights the benefit to users' privacy in id/loc
since third parties cannot way to correlate addresses to devices or
that different flows have the same source. Obviously, we want to
eliminate NAT with IPv6, but we need an answer to users' privacy.
id/loc can provide this.

Tom

---

From: Ca By <[email-masked]>
Date: Wed, 13 Dec 2017 18:44:35 +0000

> eliminate NAT with IPv6, but we need an answer to users' privacy.

I do not believe ILA provide a superior privacy expeirence compared to what
my 464XLAT subscribers today.

Can you compare and contrast today’s current state (Major metro area agg +
privacy extensions pdp lives less than 12 hrs ) vs ILA

CB

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 13 Dec 2017 10:58:03 -0800

Right, agree.

Dino

> On Dec 13, 2017, at 10:38 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 13 Dec 2017 10:59:38 -0800

That is where encapsulation has advantages. The inner header can be encrypted. With translation, since there is only one header, you cannot encrypt it.

There’s no such thing as a free lunch.  ;-)

Dino

> On Dec 13, 2017, at 10:44 AM, Ca By <[email-masked]> wrote:
> 
> 
> I do not believe ILA provide a superior privacy expeirence compared to what my 464XLAT subscribers today. 
> 
> Can you compare and contrast today’s current state (Major metro area agg + privacy extensions pdp lives less than 12 hrs ) vs ILA 
> 
> CB
> 
> 
> 
> > Dino
> >

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 Dec 2017 11:01:16 -0800

> privacy extensions pdp lives less than 12 hrs ) vs ILA
Ca,

I'll compare to NAT since that is a good baseline.

The privacy property of NAT is that every connection effectively gets
a different source address. Without the NAT mapping information a
third party cannot:

 1) correlate a source address in flow to the original sending device
 2) correlate that two flows that they are from the same source or
have any meaningful relationship
 3) infer the phsysical location of the device other then maybe at the
granulatity of location of the NAT device

Privacy extensions (RFC4941) which I assume your referring to, is ten
years old, can't provide a users any quantitative guarantee of
privacy, and I have postulated a trivial exploit to defeat privacy
mechanisms that rely on address rotation with any frequency other than
address per connection. This was a discussion in 6man.

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 13 Dec 2017 19:01:52 +0000

If one wants to offload traffic to applications/os (as alluded, which is happening already) that’s fine – it’s would be only part of the default bearer.
However, I would definitely note the complex mechanisms out there for voice (voLTE) would be extended for other QCIs which are projected to be used for 5G i.e., URLLC slice and/or [low-latency + high throughput] slices.
Here you ought to maintain not only the current non-default bearer characteristics but even more.
Slowly the* gains* you might originally see would be offset by increased traffic in other slices. Offload definitely useful but doesn’t reduce underlying complexity.

ID/LOC has the potential to eliminate some of it however lot of issues need to be ironed out to fit into the 3GPP model.   A long road ahead..
So, I do see these two topics are orthogonal to each other.

--
Uma C.

From: 5gangip [mailto:[email-masked]] On Behalf Of Ca By
Sent: Wednesday, December 13, 2017 9:04 AM
To: Alexandre Petrescu <[email-masked]>
Cc: [email-masked]
Subject: Re: [5gangip] MINUTES of side meeting in Singapore

On Wed, Dec 13, 2017 at 6:36 AM Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

Le 13/12/2017 à 14:58, Ca By a écrit :
>
> On Wed, Dec 13, 2017 at 12:51 AM Saleem Bhatti <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>
>
>>     On 13 Dec 2017, at 03:21, Tom Herbert <[email-masked]<mailto:[email-masked]>
>>     <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>     I believe we

Alex

>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 13 Dec 2017 19:49:14 +0000

Cameron;

On 13 Dec 2017, at 13:58, Ca By <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Dec 13, 2017 at 12:51 AM Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:

I believe we

+1

Cheers,
--/Saleem

I can not see Tom's comment claiming a panacea. He states a belief, and then makes an assertion - that is what I was agreeing with! :-)

I have not seen any economic models. I would be grateful for any pointers to such things.

There is an economic insentive for 3gpp operators to minimize the amount of traffic carried in the traditional network, and transfer the onus of fine grain session management and mobility to the app / os

That is fair enough.

Cheers,
--/Saleem

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Dec 2017 18:06:45 +0100

Le 13/12/2017 à 18:03, Ca By a écrit :
> 
> On Wed, Dec 13, 2017 at 6:36 AM Alexandre Petrescu 
>      > On Wed, Dec 13, 2017 at 12:51 AM Saleem Bhatti
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >
>      >>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>      >>
>      >>     I believe we

For me, as end user of multiple network operators simultaneously, I do 
consider it as a problem.

In a car, the DNS resolver is not the DNS resolver of the first-hop 
cellular operator.

In the Internet, all DNS resolvers have the same view, whereas NAT64 
introduces alternative views.

Alex

>     <mailto:[email-masked] <mailto:[email-masked]>>