Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-01.txt

[<[e-mail]>]

And more <dl>in-line </dl> ☺

From: Ca By [mailto:[e-mail]]
Sent: 23 May 2017 17:51
To: Lake D Mr (PG/R - Elec Electronic Eng) <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-01.txt

Thanks for the feedback, inline.

On Tue, May 23, 2017 at 9:19 AM, <[e-mail]<mailto:[e-mail]>> wrote:
Various comments, agreements, disagreements <dl> in-line </dl>.  Plus I’m cc-ing the IDEAS BoF list as I think we have a degree of cross-over here.

D

From: 5gangip [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Ca By
Sent: 23 May 2017 16:52
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-01.txt

Folks,

I remain very skeptical about the value of this group's collected protocols.  The scope overlaps with work in the 3GPP, contradicts work in the 3GPP, and the proposed ideas here are not obviously high value or fit for the internet or mobile networks.

Don't get me wrong, i am not in love with the 3GPP and i think there is a lot to improve on many fronts.  But,  MAMS and LISP and ILA are not on the short list of approaches i would hold up the 3GPP and say this is a better way.  In fact, MAMS as a proxy and ILA as a NAT are exactly the legacy telco stuff i would expect the IETF to work against in favor of a more secure, more salable, and more end-to-end internet.

AFAIK, FMC is already solved today.  My very own iPhone can make calls on WiFi, LTE, and switch between the 2 -- this is all standard 3GPP work from IMS. When i sit outside my house with bad wifi, the UE bounces between WiFi and LTE endlessly, but this unstable network does not interrupt me streaming Youtube.  So, i just don't see a problem to be solved here, especially if it incurs a great deal of complexity and state and signalling.  That said, MIF and Happy Eyeballs both address this issue of performance and network selection -- and i would strongly suggest the UE is in the best position to determine network quality and user experience.

<dl> Not sure I agree with this statement.  In LTE, you can determine an exactl quality (QCI) and setup up both a radio bearer and an IP level transport profile to guarantee a defined throughput.  Today, this only goes as far as the IMS core, but that is because we have no mechanism to extend QoS policy and admission beyond the bounds of a single operator.  The UE works with the network, both IP and RAN, to maintain the QoE against the required level.   This then becomes a pure matter of coverage at sufficient density to ensure quality.

You cannot define throughput in the real world.  You can ask for 100mb/s, but if there is only 5mb/s available (for whatever reason), you get 5mb/s.  3GPP is only capable of setting a ceiling QoS, it can never set a floor, because RF is hard.  Very hard, so hard that is not reasonable to ever state you can set a quality / speed floor in a terms of service.

<dl> Not sure I agree.   The ability to make different grades of voice call quality in LTE is determined by the radio coverage – the modulation method chosen asserts that.   If your RAN quality drops below a threshold, you will be dropped to a circuit-switched voice session.

You can define SLA in RF – look at DAB which offers defined service which varies by multiplex and offers absolute fixed bit-rates (which change according to the programme being transmitted).  This IS possible in planned RF systems such as cellular, DMB, DAB, DTT, etc.  It is not possible in shared/unmanaged spectrum systems such as WiFi. </dl>


When you attach to WiFi, all bets are off.  The UE is unable to make any judgement as to the quality of ANY part of the transport, whether RAN or IP network and service degradation is not graceful.   More and more I am finding LTE much more reliable than local WiFi + wired Internet for voice calls (plus cheaper – LTE service plans are tending towards free in many geographies whereas hotels still seem to want to charge HUGE amounts for bad WiFi). </dl>

This is not correct, the UE absolutely makes actionable quality judgement on network paths today

See Apple Wi-Fi assist https://support.apple.com/en-us/HT205296

Or selecting based on destination address performance available in DNS with Happy Eyeballs https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00

MP-TCP https://www.ietfjournal.org/multipath-tcp-deployments/

<dl> But you still cannot set an end-to-end quality with any of these methods.  You can second-guess the possible path from the content to you, but at-best, it is a guess.  In VoLTE, I have a dedicated bearer, with packets associated with voice placed over specific modulation portions.  It is more like defining and policing Enterprise-class voice in a campus network with an admission engine and placing voice packets into queues with defined drop/latency.  It is possible to do that in 9 different structures in LTE and theoretically possible to associate different services with those constructs. </dl>


<dl> Separate item.  On the YouTube/CDN side, many operators would like the ability to be able to offer defined service levels based on content – we have 9 QCIs in LTE (and more in 5GNR) but we currently only use 2.   If we had the ability to expose the mechanism by which content providers could offer a better service level across the air-interface, then you could see the way to a revenue-sharing model between OTTs and MNOs through a settlement system (much as happens in many other shared networks such as rail, electricity, gas, water). </dl>

This functionality is already treated by 3GPP PCC functions and deployed broadly.

<dl> CDNs do not make use of anything other than the Default Bearer.  What I’d like to see is, for example, BBC iPlayer traffic coming to my mobile over a “video” bearer which gives an SLA better than Default, but not as good as the IMS bearer. </dl>


I can't get over it this reduction: MAMs adds a proxy and ILA adds a NAT.  I just don't think that is architecturally wise in 4G or 5G.   They just can't  scale in a gigabit broadband 5G usecase [which is the usecase that pays the bills, not the pie in the sky stuff], and don't add meaningful value, and simply detract value at scale.  Also, ILA and MAMs takes a lot of work on the UE.  Getting changes into the UE is very hard, it took 10 years from the standardization of IMS to get functional IMS client (VoLTE) deployed at scale.

Finally, the 5G ship has already sailed.  Many network are "launching 5G" this year, and more networks (including the one i work at ) are committed to launching "real 5G" in the next 2 to 3 years.  None of the work in this group is within that 5G scope AFAIK. So, it may be most appropriate to carry on the effort at 6G to avoid folks getting confused.

<dl> The 5G NR ship may have sailed, but 23.501 is FULL of holes when it comes to the core network.  In fact, 23.501 is proposing using the SAME protocols and the SAME anchor as in current LTE EPC.  My guess is that we’ll see a 2-step approach to 5G – 5GNR introduced for 2018/2020 time-frame; 5G New Core in the 2020/2025 time-frame.  PLENTY of time for IETF and 3GPP to fix some of the anchor/latency issues.  </dl>

<dl> We should also not lose sight that the things which current EPC does well (streaming with large packets from centralised CDNs) are in violent opposition to a number of 5G use-cases such as the transport of very infrequent, small-sized data such as in IoT.  When you have a video segment comprising many ~1500 Byte payloads, addressing overhead length is negligible.  When you are sending a 2 Byte temperature reading once every 2 hours and there are 9 or 10 layers of addressing, this becomes very inefficient. </dl>


I do not believe this use case is new or under-served.   It would be more helpful to specifically quantify a problem. The description you gave needs a tighter and more specific problem to solve, and it would be helpful to understand how existing approachs (NB-IOT) are insufficient

<dl> If by NB-IoT you mean one of the LTE CAT-Mx, then they use the same NAS as regular LTE.   So, between UE and SGi on the S1 interface, I will see at least two, possibly three layers of IP addressing, two possibly three layer of GTP, an application addressing structure and at least one transport header (MPLS).   Observation taken from a large MNO showed that on-the-fibre between an eNB and an S-GW, at some points 10 addressing layers were seen. </dl>

I still hold out hope for ILNP to replace the mobility core at some future date, the radio network just does a simple authentication and that is all. But, that is my own dream of a simpler world :)  I would suggest the standard we look for in this group is:  what can we remove from 3GPP 5G / 6G, not what we can add.  How does the work in this group reduce NET signalling and user-plane modification from the 3GPP steady state?  How is that quantified?

CB

<dl> Side Comment.   There is much work here in IDEAS, 5gangip and netslices which seems to be inter-related and VERY relevant.  Somehow, we need to ensure that the groups work together.  I actually think this problem space is broader than the thee BoFs currently being planned… </dl>



On Tue, May 23, 2017 at 2:53 AM, <[e-mail]<mailto:[e-mail]>> wrote:
Dear all,
We have updated the PS draft on 5G IP issues regarding the planned BoF in Prague.
Please check whether we have addressed the comments correctly and continue to discuss this towards further improvement.
Thanks a lot – also on behalf of Roland, SungHoon, and Behcet

Best Regards
Dirk

---------- Forwarded message ----------
From: <[e-mail]<mailto:[e-mail]>>
Date: Mon, May 22, 2017 at 1:22 PM
Subject: New Version Notification for draft-xyx-5gip-ps-01.txt
To: Behcet Sarikaya <[e-mail]<mailto:[e-mail]>>, Tom Herbert <[e-mail]<mailto:[e-mail]>>, Roland Schott <[e-mail]<mailto:[e-mail]>>, SungHoon Seo <[e-mail]<mailto:[e-mail]>>, Roland Schott <[e-mail]<mailto:[e-mail]>>, Dirk von Hugo <[e-mail]<mailto:[e-mail]>>, Satish Kanugovi <[e-mail]<mailto:[e-mail]>>



A new version of I-D, draft-xyx-5gip-ps-01.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-xyx-5gip-ps
Revision:       01
Title:          5G IP Access and Session Management Protocols
Document date:  2017-05-22
Group:          Individual Submission
Pages:          14
URL:            https://www.ietf.org/internet-drafts/draft-xyx-5gip-ps-01.txt
Status:         https://datatracker.ietf.org/doc/draft-xyx-5gip-ps/
Htmlized:       https://tools.ietf.org/html/draft-xyx-5gip-ps-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xyx-5gip-ps-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-xyx-5gip-ps-01

Abstract:
   This document builds upon 5G IP issues work and - based on a
   simplified 5G system architecture - attempts to make the case for a
   possible set of new protocols that need to be developed to be used
   among various virtualized functions in a 5G network.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat


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