Subject: Re: [5gangip] To initiate user-plane study work in 3GPP

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Nov 2017 13:23:55 +0100

Le 17/10/2017 à 23:15, [email-masked] a écrit :
> Bob
> 
> This is the key statement for me:
> 
> “A study group would have to work out what services GTP provides”
> 
> Both in this group and related efforts (e.g. IDEAS at IETF, NGP at 
> ETSI), we need to consider how it is that mobile networks are built.
> 
> In terms of P2P, traffic on today’s mobile networks is predominantly 
> anchored at a central point, not P2P despite the associated engineering 
> inefficiencies.   There are very good reasons for this:
> 
>   * It makes LI very easy to implement
>   * It makes association of traffic with user clear allowing simple
>     billing mechanisms
>   * Mobility events are handled quickly and with minimal packet loss
> 
> In terms of the major use-cases today (voice over LTE and mobile 
> broadband) as they move to 5G, I really don’t see any need to change the 
> underlying tunnelling protocol because It Works.

It works, but does it scale to IPv6 size?

Alex

> 
> However, for NEW 5G use-cases such as Ultra-Low Latency and edge-based 
> services we should be considering whether GTP is the correct choice 
> provided we can meet the commercial and regulatory requirements of the 
> MNOs in terms of LI and charging.
> 
> David
> 
> *From:*5gangip [mailto:[email-masked]] *On Behalf Of *Robert 
> Moskowitz
> *Sent:* 17 October 2017 05:52
> *To:* [email-masked]; Satoru Matsushima <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [5gangip] To initiate user-plane study work in 3GPP
> 
> Behcet and Satoru,
> 
> Last year I did a study of GTPv1U and worked out a different approach 
> that would better support P2P communications without the need of a home 
> proxy agent.  You can see part of it in:
> 
> draft-moskowitz-hip-ipnhip-02.txt
> 
> But I learned that there is tremendous resistance to any change away 
> from GTP, even a partial change.  A study group would have to work out 
> what services GTP provides.  Which services it does well and which it 
> does poorly.  Then how to better meet the service needs today and going 
> forward.
> 
> Bob
> 
> On 10/16/2017 04:12 PM, Behcet Sarikaya wrote:
> 
>     Hi Satoru,
> 
>     Thanks for the info.
> 
>     Can you please explain the objective items in your WID?
> 
>     It seems like according to TR 29.891 that you mentioned, Release 15
>     user plane protocol is GTPv1U and control plane protocol for SBA is
>     HTTP.
> 
>     Regards,
> 
>     Behcet
> 
>     On Mon, Oct 16, 2017 at 4:13 AM, Satoru Matsushima
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> 
>         FYI. I’d submit a contribution to propose a new study item which
>         is to initiate user-plane protocol study work in 3GPP CT4 WG.
> 
>         http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_80_Kochi/Docs/C4-175098.zip
> 
>         Please take a look at the doc from above link. I'd appreciate
>         any your support if you think it makes sense.
> 
>         Cheers,
>         --satoru
>         _______________________________________________
>         5gangip mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/5gangip
> 
> 
> 
> 
>     _______________________________________________
> 
>     5gangip mailing list
> 
>     [email-masked] <mailto:[email-masked]>
> 
>     https://www.ietf.org/mailman/listinfo/5gangip
> 
> 
> 
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Nov 2017 13:26:53 +0100

Le 19/10/2017 à 04:52, Satoru Matsushima a écrit :
> Thank you Dirk,
> 
> Yes that presentation made by George has much encouraged ietf community.
> Other key facts which the justification text mentioned are following:
> 
> o IAB statement on IPv6
>    https://www.iab.org/2016/11/07/iab-statement-on-ipv6/
> 
> o IPv6 deployment measurement
>    http://www.worldipv6launch.org/measurements/
> 
> We can see big number of adoption rate for cellular operators especially in US. T-Mobile US and Verizon Wireless exceed 80%, 47.51% for ATT Wireless, and 59% for Sprint Wireless.

YEs, these networks carry much IPv6,
but is it carried mostly in GTP/UDP/IPv4?

Alex

> 
> Cheers,
> --satoru
> 
> 
>> 2017/10/19 2:17、<[email-masked]> <[email-masked]>のメール:
>>
>> Dear all,
>> I completely agree that we (i.e. at IETF community) should start work on potential protocol or framework solutions for 3GPP - even before 5G requirements (in architecture documents) are fully specified which as Georg in Prague pointed out https://datatracker.ietf.org/meeting/99/materials/slides-99-edu-sessk-3gpp-ietf-collaboration-on-5g/ is expected for end of this year.
>> And I also think that a major role will play Identity / Locator Separated protocols like LISP, ILNP, ILA ... supporting multiple types of mobility by choosing correspondingly adapted configurations ... which would fit to service-tailored network slicing ideas.
>> Thanks!
>> Best Regards
>> Dirk
>> -----Original Message-----
>> From: 5gangip [mailto:[email-masked]] On Behalf Of Satoru Matsushima
>> Sent: Mittwoch, 18. Oktober 2017 11:11
>> To: [email-masked]; [email-masked]; [email-masked]; <[email-masked]>
>> Cc: [email-masked]
>> Subject: Re: [5gangip] To initiate user-plane study work in 3GPP
>>
>> Behcet, David, and Uma,
>>
>> Thank you for your comments. Those are really informative. And yes I agree that we need to work with 3GPP. That’s why the WID out there.
>>
>> While there’s no clear facts on future networking in 5G, I wrote up the text in justification with facts which at least IPv6 adoption has been growth and IAB recommend SDOs to review existing standards work in IPv6-only environment.
>>
>> Cheers,
>> --satoru
>>
>>
>>
>>
>>> 2017/10/18 6:52、[email-masked]:
>>>
>>> Uma
>>>
>>> I agree that X2 is a complication but this is only used temporarily to provide a fast switch-over during a mobility event.  In terms of end-to-end communication, even during an X2 event, the topology and use of a tunnel anchored at the centre remains.
>>>
>>> The issue is not the protocol but the time the underlying equipment takes to update the tunnel path.
>>>
>>> At the moment (note – AT THE MOMENT!) the use-case which requires the most expeditious switch-over and is least tolerant to packet drops due to mobility events is VoLTE and it survives very well in current S1 and X2 handover systems.
>>>
>>> I think this - “I am not sure who is “we”  (I would see that as 3GPP).”   - may be where we are struggling!  Until we have a use-case which patently fails using the current anchored GTP system, we are going to find it very hard to have an alternative solution considered.
>>>
>>> We need to work with 3GPP on this….
>>>
>>> David
>>>
>>>
>>>
>>> From: Uma Chunduri [mailto:[email-masked]]
>>> Sent: 17 October 2017 14:39
>>> To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
>>> Cc: [email-masked]
>>> Subject: RE: [5gangip] To initiate user-plane study work in 3GPP
>>>
>>> David,
>>>
>>> Agree mostly on what you said.  2 comments though..
>>>
>>>
>>>> Mobility events are handled quickly and with minimal packet loss
>>>
>>> I don’t think so. It’s an overhead for RAN mobility (X2 tunnels creation and additional control signalling for the same) and similar complication for UPF mobility.
>>>
>>>> However, for NEW 5G use-cases such as Ultra-Low Latency and edge-based services we should be considering whether GTP is the correct choice provided we can meet the commercial and regulatory requirements of the MNOs in terms of LI and charging.
>>>
>>> I am not sure who is “we”  (I would see that as 3GPP).
>>>
>>>
>>> But it’s good to put proposals  to show what layer 3 mobility entails -  like the one Bob mentioned below or  what Dino indicatedhttps://www.ietf.org/mail-archive/web/5gangip/current/msg00571.html
>>>
>>>
>>> --
>>> Uma C.
>>>
>>> From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
>>> Sent: Tuesday, October 17, 2017 2:15 PM
>>> To: [email-masked]; [email-masked]; [email-masked]
>>> Cc: [email-masked]
>>> Subject: Re: [5gangip] To initiate user-plane study work in 3GPP
>>>
>>> Bob
>>>
>>> Both in this group and related efforts (e.g. IDEAS at IETF, NGP at ETSI), we need to consider how it is that mobile networks are built.
>>>
>>> In terms of P2P, traffic on today’s mobile networks is predominantly anchored at a central point, not P2P despite the associated engineering inefficiencies.   There are very good reasons for this:
>>>
>>> 	• It makes LI very easy to implement
>>> 	• It makes association of traffic with user clear allowing simple billing mechanisms
>>> 	• Mobility events are handled quickly and with minimal packet loss
>>>
>>> In terms of the major use-cases today (voice over LTE and mobile broadband) as they move to 5G, I really don’t see any need to change the underlying tunnelling protocol because It Works.
>>>
>>> However, for NEW 5G use-cases such as Ultra-Low Latency and edge-based services we should be considering whether GTP is the correct choice provided we can meet the commercial and regulatory requirements of the MNOs in terms of LI and charging.
>>>
>>> David
>>>
>>> From: 5gangip [mailto:[email-masked]] On Behalf Of Robert Moskowitz
>>> Sent: 17 October 2017 05:52
>>> To: [email-masked]; Satoru Matsushima <[email-masked]>
>>> Cc: [email-masked]
>>> Subject: Re: [5gangip] To initiate user-plane study work in 3GPP
>>>
>>> Behcet and Satoru,
>>>
>>> Last year I did a study of GTPv1U and worked out a different approach that would better support P2P communications without the need of a home proxy agent.  You can see part of it in:
>>>
>>> But I learned that there is tremendous resistance to any change away from GTP, even a partial change.  A study group would have to work out what services GTP provides.  Which services it does well and which it does poorly.  Then how to better meet the service needs today and going forward.
>>>
>>> Bob
>>>
>>> It seems like according to TR 29.891 that you mentioned, Release 15 user plane protocol is GTPv1U and control plane protocol for SBA is HTTP.
>>>
>>> Regards,
>>> Behcet
>>>
>>> On Mon, Oct 16, 2017 at 4:13 AM, Satoru Matsushima <[email-masked]> wrote:
>>> FYI. I’d submit a contribution to propose a new study item which is to initiate user-plane protocol study work in 3GPP CT4 WG.
>>>
>>> Please take a look at the doc from above link. I'd appreciate any your support if you think it makes sense.
>>>
>>> Cheers,
>>> --satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 14 Nov 2017 00:54:27 +0800

Alex,

You’re right as others have admitted. But you can see more stacked layers underneath of GTP/UDP/IPv4
Please take a look at the attached picture which one of the realities happened in some operator.

Cheers,
--satoru

> 2017/11/12 20:26、Alexandre Petrescu <[email-masked]>のメール:
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 15 Nov 2017 15:46:57 +0100

Satoru,

I see two distinct "VPN label" layers.  I can agree with two IP layers 
in same stack, but two VPN layers too?

Arent these too many layers?

For the question of which one of the realities happened in some operator 
- I can ask locally about which of these layers (VPN label, LSP label, 
VLAN ID, SMAC, DMAC, VPN label, LSP label, SMAC, DMAC) are seen at the PGW.

Alex

Le 13/11/2017 à 17:54, Satoru Matsushima a écrit :
>> 2017/11/12 20:26、Alexandre Petrescu <[email-masked] 
>> <mailto:[email-masked]>>のメール:
>>
>>
>>
>>> We can see big number of adoption rate for cellular operators 
>>> especially in US. T-Mobile US and Verizon Wireless exceed 80%, 47.51% 
>>> for ATT Wireless, and 59% for Sprint Wireless.
>>
>>>> 2017/10/19 2:17、<[email-masked] 
>>>> <mailto:[email-masked]>> <[email-masked] 
>>>> <mailto:[email-masked]>>のメール:
>>>>
>>>> Dear all,
>>>> I completely agree that we (i.e. at IETF community) should start 
>>>> work on potential protocol or framework solutions for 3GPP - even 
>>>> before 5G requirements (in architecture documents) are fully 
>>>> specified which as Georg in Prague pointed out 
>>>> https://datatracker.ietf.org/meeting/99/materials/slides-99-edu-sessk-3gpp-ietf-collaboration-on-5g/ 
>>>> is expected for end of this year.
>>>> And I also think that a major role will play Identity / Locator 
>>>> Separated protocols like LISP, ILNP, ILA ... supporting multiple 
>>>> types of mobility by choosing correspondingly adapted configurations 
>>>> ... which would fit to service-tailored network slicing ideas.
>>>> Thanks!
>>>> Best Regards
>>>> Dirk
>>>> Thank you for your comments. Those are really informative. And yes I 
>>>> agree that we need to work with 3GPP. That’s why the WID out there.
>>>>
>>>> While there’s no clear facts on future networking in 5G, I wrote up 
>>>> the text in justification with facts which at least IPv6 adoption 
>>>> has been growth and IAB recommend SDOs to review existing standards 
>>>> work in IPv6-only environment.
>>>>
>>>> Cheers,
>>>> --satoru
>>>>
>>>>
>>>>
>>>>
>>>>> I agree that X2 is a complication but this is only used temporarily 
>>>>> to provide a fast switch-over during a mobility event.  In terms of 
>>>>> end-to-end communication, even during an X2 event, the topology and 
>>>>> use of a tunnel anchored at the centre remains.
>>>>>
>>>>> At the moment (note – AT THE MOMENT!) the use-case which requires 
>>>>> the most expeditious switch-over and is least tolerant to packet 
>>>>> drops due to mobility events is VoLTE and it survives very well in 
>>>>> current S1 and X2 handover systems.
>>>>>
>>>>> I think this - “I am not sure who is “we”  (I would see that as 
>>>>> 3GPP).”   - may be where we are struggling!  Until we have a 
>>>>> use-case which patently fails using the current anchored 
>>>>> GTP system, we are going to find it very hard to have an 
>>>>> alternative solution considered.
>>>>>
>>>>> To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>; 
>>>>> [email-masked]; [email-masked]; [email-masked]
>>>>> Cc: [email-masked]
>>>>> I don’t think so. It’s an overhead for RAN mobility (X2 tunnels 
>>>>> creation and additional control signalling for the same) and 
>>>>> similar complication for UPF mobility.
>>>>>
>>>>>> However, for NEW 5G use-cases such as Ultra-Low Latency and 
>>>>>> edge-based services we should be considering whether GTP is the 
>>>>>> correct choice provided we can meet the commercial and regulatory 
>>>>>> requirements of the MNOs in terms of LI and charging.
>>>>>
>>>>> But it’s good to put proposals  to show what layer 3 mobility 
>>>>> entails -  like the one Bob mentioned below or  what Dino 
>>>>> indicatedhttps://www.ietf.org/mail-archive/web/5gangip/current/msg00571.html
>>>>>
>>>>>
>>>>> --
>>>>> Uma C.
>>>>>
>>>>> In terms of P2P, traffic on today’s mobile networks is 
>>>>> predominantly anchored at a central point, not P2P despite the 
>>>>> associated engineering inefficiencies.   There are very 
>>>>> good reasons for this:
>>>>>
>>>>> broadband) as they move to 5G, I really don’t see any need to 
>>>>> change the underlying tunnelling protocol because It Works.
>>>>>
>>>>> However, for NEW 5G use-cases such as Ultra-Low Latency and 
>>>>> edge-based services we should be considering whether GTP is the 
>>>>> correct choice provided we can meet the commercial and regulatory 
>>>>> requirements of the MNOs in terms of LI and charging.
>>>>>
>>>>> David
>>>>>
>>>>> Last year I did a study of GTPv1U and worked out a different 
>>>>> approach that would better support P2P communications without the 
>>>>> need of a home proxy agent.  You can see part of it in:
>>>>>
>>>>> But I learned that there is tremendous resistance to any change 
>>>>> away from GTP, even a partial change.  A study group would have to 
>>>>> work out what services GTP provides.  Which services it does well 
>>>>> and which it does poorly.  Then how to better meet the service 
>>>>> needs today and going forward.
>>>>>
>>>>> Bob
>>>>>
>>>>> <[email-masked]> wrote:
>>>>> FYI. I’d submit a contribution to propose a new study item which is 
>>>>> to initiate user-plane protocol study work in 3GPP CT4 WG.
>>>>>
>>>>> Please take a look at the doc from above link. I'd appreciate any 
>>>>> your support if you think it makes sense.
>>>>>
>>>>> Cheers,
>>>>> --satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 16 Nov 2017 14:36:39 +0800

Alex, 

Let us imagine a case where under VPN label is imposed by a transport service operator who provides backhaul connectivity for multiple mobile operators. And upper VPN label is imposed by a mobile operator who need to create three or more VPNs for each mobile user-plane, control-plane O&M and if any other purposes respectively even just within the mobile operator for example.

Cheers,
--satoru

> 2017/11/15 22:46、Alexandre Petrescu <[email-masked]>のメール:
> 
> Satoru,
> 
> I see two distinct "VPN label" layers.  I can agree with two IP layers in same stack, but two VPN layers too?
> 
> For the question of which one of the realities happened in some operator - I can ask locally about which of these layers (VPN label, LSP label, VLAN ID, SMAC, DMAC, VPN label, LSP label, SMAC, DMAC) are seen at the PGW.
> 
> Alex
> 
>>> 2017/11/12 20:26、Alexandre Petrescu <[email-masked] <mailto:[email-masked]>>のメール:
>>> 
>>> 
>>> 
>>>>> 2017/10/19 2:17、<[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>のメール:
>>>>> 
>>>>> Dear all,

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Nov 2017 08:21:44 +0100

Satoru,

I understand then.  Thank you for the explanation.

I think there are some problems with this.  Multiple encapsulations lead
to loss of efficiency.  This leads to lesser bandwidth.  For voice
calls, this can mean less quality of voice, or longer connection
establishment times.

For example, now in Singapour I experience very long connection
establishment times on my phone with SIM from home.  My operator is an 
MVNO (Mobile Virtual Network Operator) whose transport depends on 
another operator in my home country.  Here is yet another operator.

On another hand, skype has same connection establishment time as when I
am at home.

Alex

Le 16/11/2017 à 07:36, Satoru Matsushima a écrit :
> Alex,
> 
> Let us imagine a case where under VPN label is imposed by a transport
> service operator who provides backhaul connectivity for multiple
> mobile operators. And upper VPN label is imposed by a mobile operator
> who need to create three or more VPNs for each mobile user-plane,
> control-plane O&M and if any other purposes respectively even just
> within the mobile operator for example.
> 
> Cheers, --satoru
> 
>> I see two distinct "VPN label" layers.  I can agree with two IP
>> layers in same stack, but two VPN layers too?
>> 
>> For the question of which one of the realities happened in some
>> operator - I can ask locally about which of these layers (VPN
>> label, LSP label, VLAN ID, SMAC, DMAC, VPN label, LSP label, SMAC,
>> DMAC) are seen at the PGW.
>> 
>> Alex
>> 
>>> Alex, You’re right as others have admitted. But you can see more
>>> stacked layers underneath of GTP/UDP/IPv4 Please take a look at
>>> the attached picture which one of the realities happened in some
>>> operator. Cheers, --satoru
>>>>> Thank you Dirk, Yes that presentation made by George has much
>>>>> encouraged ietf community. Other key facts which the
>>>>> justification text mentioned are following: o IAB statement
>>>>> on IPv6 
>>>>> https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ o IPv6
>>>>> deployment measurement 
>>>>> http://www.worldipv6launch.org/measurements/ We can see big
>>>>> number of adoption rate for cellular operators especially in
>>>>> US. T-Mobile US and Verizon Wireless exceed 80%, 47.51% for
>>>>> ATT Wireless, and 59% for Sprint Wireless.
>>>> 
>>>> YEs, these networks carry much IPv6, but is it carried mostly
>>>> in GTP/UDP/IPv4?
>>>> 
>>>> Alex
>>>> 
>>>>> Cheers, --satoru
>>>>>> <mailto:[email-masked]>> <Dirk.von-
>>>>>> [email-masked] <mailto:[email-masked]>>のメール:
>>>>>> 
>>>>>> Dear all, I completely agree that we (i.e. at IETF
>>>>>> community) should start work on potential protocol or
>>>>>> framework solutions for 3GPP - even before 5G requirements
>>>>>> (in architecture documents) are fully specified which as
>>>>>> Georg in Prague pointed out
>>>>>> is expected for end of this year. And I also think that a
>>>>>> major role will play Identity / Locator Separated protocols
>>>>>> like LISP, ILNP, ILA ... supporting multiple types of
>>>>>> mobility by choosing correspondingly adapted configurations
>>>>>> ... which would fit to service-tailored network slicing
>>>>>> ideas. Thanks! Best Regards Dirk -----Original
>>>>>> Message----- From: 5gangip
>>>>>> [mailto:[email-masked]] On Behalf Of Satoru
>>>>>> Matsushima Sent: Mittwoch, 18. Oktober 2017 11:11 To:
>>>>>> [email-masked]; [email-masked];
>>>>>> [email-masked]; <[email-masked]> Cc:
>>>>>> [email-masked] Subject: Re: [5gangip] To initiate
>>>>>> user-plane study work in 3GPP
>>>>>> 
>>>>>> Behcet, David, and Uma,
>>>>>> 
>>>>>> Thank you for your comments. Those are really informative.
>>>>>> And yes I agree that we need to work with 3GPP. That’s why
>>>>>> the WID out there.
>>>>>> 
>>>>>> While there’s no clear facts on future networking in 5G, I
>>>>>> wrote up the text in justification with facts which at
>>>>>> least IPv6 adoption has been growth and IAB recommend SDOs
>>>>>> to review existing standards work in IPv6-only
>>>>>> environment.
>>>>>> 
>>>>>> Cheers, --satoru
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> I agree that X2 is a complication but this is only used
>>>>>>> temporarily to provide a fast switch-over during a
>>>>>>> mobility event.  In terms of end-to-end communication,
>>>>>>> even during an X2 event, the topology and use of a tunnel
>>>>>>> anchored at the centre remains.
>>>>>>> 
>>>>>>> The issue is not the protocol but the time the underlying
>>>>>>> equipment takes to update the tunnel path.
>>>>>>> 
>>>>>>> At the moment (note – AT THE MOMENT!) the use-case which
>>>>>>> requires the most expeditious switch-over and is least
>>>>>>> tolerant to packet drops due to mobility events is VoLTE
>>>>>>> and it survives very well in current S1 and X2 handover
>>>>>>> systems.
>>>>>>> 
>>>>>>> I think this - “I am not sure who is “we”  (I would see
>>>>>>> that as 3GPP).”   - may be where we are struggling!
>>>>>>> Until we have a use-case which patently fails using the
>>>>>>> current anchored GTP system, we are going to find it very
>>>>>>> hard to have an alternative solution considered.
>>>>>>> 
>>>>>>> From: Uma Chunduri [mailto:[email-masked]] Sent:
>>>>>>> 17 October 2017 14:39 To: Lake D Mr (PG/R - Elec
>>>>>>> Electronic Eng) <[email-masked]>;
>>>>>>> [email-masked]; [email-masked];
>>>>>>> [email-masked] Cc: [email-masked] Subject:
>>>>>>> RE: [5gangip] To initiate user-plane study work in 3GPP
>>>>>>> 
>>>>>>> David,
>>>>>>> 
>>>>>>> I don’t think so. It’s an overhead for RAN mobility (X2
>>>>>>> tunnels creation and additional control signalling for
>>>>>>> the same) and similar complication for UPF mobility.
>>>>>>> 
>>>>>>>> However, for NEW 5G use-cases such as Ultra-Low Latency
>>>>>>>> and edge-based services we should be considering
>>>>>>>> whether GTP is the correct choice provided we can meet
>>>>>>>> the commercial and regulatory requirements of the MNOs
>>>>>>>> in terms of LI and charging.
>>>>>>> 
>>>>>>> But it’s good to put proposals  to show what layer 3
>>>>>>> mobility entails -  like the one Bob mentioned below or
>>>>>>> what Dino
--
>>>>>>> Uma C.
>>>>>>> 
>>>>>>> From: 5gangip [mailto:[email-masked]] On Behalf
>>>>>>> Of [email-masked] Sent: Tuesday, October 17, 2017
>>>>>>> 2:15 PM To: [email-masked]; [email-masked];
>>>>>>> [email-masked] Cc: [email-masked] Subject:
>>>>>>> Re: [5gangip] To initiate user-plane study work in 3GPP
>>>>>>> 
>>>>>>> Bob
>>>>>>> 
>>>>>>> Both in this group and related efforts (e.g. IDEAS at
>>>>>>> IETF, NGP at ETSI), we need to consider how it is that
>>>>>>> mobile networks are built.
>>>>>>> 
>>>>>>> predominantly anchored at a central point, not P2P
>>>>>>> despite the associated engineering inefficiencies.
>>>>>>> There are very good reasons for this:
>>>>>>> 
>>>>>>> • It makes LI very easy to implement • It makes
>>>>>>> association of traffic with user clear allowing simple
>>>>>>> billing mechanisms • Mobility events are handled quickly
>>>>>>> and with minimal packet loss
>>>>>>> 
>>>>>>> In terms of the major use-cases today (voice over LTE and
>>>>>>> mobile broadband) as they move to 5G, I really don’t see
>>>>>>> any need to change the underlying tunnelling protocol
>>>>>>> because It Works.
>>>>>>> 
>>>>>>> However, for NEW 5G use-cases such as Ultra-Low Latency
>>>>>>> and edge-based services we should be considering whether
>>>>>>> GTP is the correct choice provided we can meet the
>>>>>>> commercial and regulatory requirements of the MNOs in
>>>>>>> terms of LI and charging.
>>>>>>> 
>>>>>>> David
>>>>>>> 
>>>>>>> From: 5gangip [mailto:[email-masked]] On Behalf
>>>>>>> Of Robert Moskowitz Sent: 17 October 2017 05:52 To:
>>>>>>> [email-masked]; Satoru Matsushima
>>>>>>> <[email-masked]> Cc: [email-masked] 
>>>>>>> Last year I did a study of GTPv1U and worked out a
>>>>>>> different approach that would better support P2P
>>>>>>> communications without the need of a home proxy agent.
>>>>>>> You can see part of it in:
>>>>>>> 
>>>>>>> But I learned that there is tremendous resistance to any
>>>>>>> change away from GTP, even a partial change.  A study
>>>>>>> group would have to work out what services GTP provides.
>>>>>>> Which services it does well and which it does poorly.
>>>>>>> Then how to better meet the service needs today and going
>>>>>>> forward.
>>>>>>> 
>>>>>>> Bob
>>>>>>> 
>>>>>>> On 10/16/2017 04:12 PM, Behcet Sarikaya wrote: Hi
>>>>>>> Satoru,
>>>>>>> 
>>>>>>> Thanks for the info.
>>>>>>> 
>>>>>>> It seems like according to TR 29.891 that you mentioned,
>>>>>>> Release 15 user plane protocol is GTPv1U and control
>>>>>>> plane protocol for SBA is HTTP.
>>>>>>> 
>>>>>>> Regards, Behcet
>>>>>>> 
>>>>>>> <[email-masked]> wrote: FYI. I’d submit a
>>>>>>> contribution to propose a new study item which is to
>>>>>>> initiate user-plane protocol study work in 3GPP CT4 WG.
>>>>>>> 
Please take a look at the doc from above link. I'd appreciate any your 
support if you think it makes sense.
>>>>>>> 
>>>>>>> Cheers, --satoru 
>>>>>>> _______________________________________________ 5gangip
>>>>>>> mailing list [email-masked] 
>>>>>>> _______________________________________________ 5gangip
>>>>>>> mailing list [email-masked] 
>>>>>> _______________________________________________ 5gangip
>>>>>> mailing list [email-masked] 
>>>>> _______________________________________________ 5gangip
>>>>> mailing list [email-masked] <mailto:[email-masked]> 
>>>> _______________________________________________ 5gangip mailing
>>>> list [email-masked] <mailto:[email-masked]>

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 17 Nov 2017 10:35:21 +0800

Alex,

> calls, this can mean less quality of voice, or longer connection

As Cameron replied in another thread, the header tax issue has been lesser while bandwidth increased. What I mention here is that complication to correlate those stacked layers each other to meet the requirements.

Connection establishment time issue seems different from that. It more likes a control-plane signaling procedure issue.

> establishment times on my phone with SIM from home.  My operator is an MVNO (Mobile Virtual Network Operator) whose transport depends on another operator in my home country.  Here is yet another operator.
> 

So yes, that is a kind of control-plane signaling procedure issue.

Cheers,
--satoru

>>>>>> on IPv6 https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ o IPv6
>>>>>> deployment measurement http://www.worldipv6launch.org/measurements/ We can see big
>>>>>>>> <[email-masked]> Cc: [email-masked] Subject: Re: [5gangip] To initiate user-plane study work
>>>>>>>> in 3GPP
>>>>>>>> Behcet and Satoru,
>>>>>>>> Cheers, --satoru _______________________________________________ 5gangip
>>>>>>>> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/5gangip
>>>>>>>> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/5gangip
>>>>>>> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/5gangip
>>>>>> mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/5gangip
>>>>> list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/5gangip