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, <d.lake@surrey.ac.uk> 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:5gangip-bounces@ietf.org] *On Behalf Of *Ca By
> *Sent:* 23 May 2017 16:52
> *To:* Dirk.von-Hugo@telekom.de
> *Cc:* 5gangip@ietf.org
> *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.

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

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

> 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, <Dirk.von-Hugo@telekom.de> 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: <internet-drafts@ietf.org>
> Date: Mon, May 22, 2017 at 1:22 PM
> Subject: New Version Notification for draft-xyx-5gip-ps-01.txt
> To: Behcet Sarikaya <sarikaya@ieee.org>, Tom Herbert <tom@herbertland.com>,
> Roland Schott <roland.schott@telekom.de>, SungHoon Seo <sh.seo@kt.com>,
> Roland Schott <Roland.Schott@telekom.de>, Dirk von Hugo <
> dirk.von-hugo@telekom.de>, Satish Kanugovi <satish.k@nokia.com>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> 5gangip mailing list
> 5gangip@ietf.org
> https://www.ietf.org/mailman/listinfo/5gangip
>
>
>