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

[Behcet Sarikaya <[e-mail]>]

agree with David.



On Tue, May 23, 2017 at 12:18 PM, <[e-mail]> wrote:

> And more <dl>in-line </dl> J
>
>
>
> *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]> 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]] *On Behalf Of *Ca By
> *Sent:* 23 May 2017 16:52
> *To:* [e-mail]
> *Cc:* [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]> 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]>
> 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]>, Tom Herbert <[e-mail]>,
> Roland Schott <[e-mail]>, SungHoon Seo <[e-mail]>,
> Roland Schott <[e-mail]>, Dirk von Hugo <
> [e-mail]>, Satish Kanugovi <[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.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip
>
>
>
>
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip
>
>