Re: [6gip] 6G in 3GPP?

[Stewart Bryant <[e-mail]>]

David

This is a real use case. People can argue about the economics, but the inability of the existing Internet as it is deployed to deliver this real service requirement is well stated in your note. If you had stated this a year ago, this would have been considered ultra niche, but like many things the pandemic has changed the way we live work and play, and I am sure that if this service was available there would be many other uses, but those uses are currently suppressed because people simply think it is not possible.

Why not write this up as an ID, even an RFC if there are other cases, so it is on record as a referenceable requirement.

- Stewart



> On 15 Jan 2021, at 11:26, David Lake <d.lake=[e-mail]> wrote:
> 
> Toerless (and all)
> 
> (Sorry about the rant - I'm a frustrated musician and another long-ish email follows):
> 
> In fact, yesterday afternoon I was duetting with a friend 20 miles away (two pianos - Richard Rodney Bennett's Four Piece Suite for two pianos).  My playing partner, Louise, is in Reigate; I'm in Crawley.   That's about 10 miles. Her DSL provider is TalkTalk, mine is Zen.   RTTs directly between us vary from 20 to 50ms.  Ugh.
> 
> We both have 67Mbit/s DSL "services" - the bandwidth we want to use is 510kbit/s...   
> 
> We're using JackTrip (RaspberryPI with HiFiBerry and direct wired Ethernet connections - WiFi is so compromised that it is unusable).   It is MUCH better for us to use a common shared server in London (~9ms each) as the rendezvous point than it is to go point-to-point.   We're getting air-to-air latency of between 18 and 22ms (that is sound going in to microphone at one end, coming out at the other into headphones - btw that is VERY good compared to PC ADC/DAC which can be 5-10ms alone before packetisation).
> 
> That isn't good enough.  If we had two pianos in the same room, the maximum we would hit would be about 6ms and even that can be difficult (10ms = 10ft in free air) and the last thing you want is any variation in the latency - that throws ensemble playing (especially in fast passages). 
> 
> So, what I'd like to be able to do is contact my and her ISP and say "for all the packets involved in our music, guarantee that they will arrive 6ms after they are sent."   Detnet on speed, if you will... (I'll take a look at Detnet now!!!!)
> 
> You can't.  We don't have the mechanism in any part of the public Internet (bar VoLTE) to do that. 
> 
> Your point about "IP" is EXACT - I don't actually care about how the bits are arranged on the wire in any way.  What I care about is that my service is delivered in the way that I want and pay for and that I have the ability to define a required outcome.  There is nothing on today's public network that allows me to associate value with my application and have that delivered end-to-end.  I do worry that transporting my room thermometer data (2 bytes sent every minute) over cellular involves at least 4 sets of IP headers and a GTP tunnel.   That seems like a VERY bad information:overhead ratio - I wonder what the cost of processing each bit is in terms of power, minerals, production costs, shipping costs, etc...
> 
> You make a VERY interesting point here:
> 
> "IMHO the better approach is to focus on research into virtualizing the forwarding plane of interest such that it can be programmable by the actual customer. In the same way as 4G/5G cores are nowadays often only a bunch of VMs/containers in edge-DCs, the actual forwarding plane in metro-router/switches could become programmable to customers such as "advanced-QoE-slice-operators" that are also owning/developing the actual solutions/applications (such as interactive city-wide music)."
> 
> Good idea, but I'm not sure as a consumer I have enough of a view into the network to be able to do that.   Given that we have 150+ ISPs plus 25+ M(v)NOs, the complexity involved in brokering a QoE between any multiple end-points is vast.  We did a quick straw poll of one of my choirs recently - we have 140 members all within a 20 mile radius and there are over 40 different ISPs in use, each with their own anchor points.  My packets travel about 140 miles north to break out - my next door neighbour on a different ISP travel about 100 miles west.  The only common point between them despite his house being 30ft away is via an IXP.   I think we've made the Internet SO disjointed that trying to do anything other than ship packets from interface to interface is very difficult (or as you correctly say very high-level MPLS-TE paths between SPs).  Not that we shouldn't try and solve it - in fact I think if we were to try to build a proper supply-chain model it would be fundamental that we associate value/contract/outcome.  This is as-much an economic problem as it is an engineering problem but like you I see little appetite I the IETF at the moment to look at the Internet in these terms.
> 
> So my question is if we couldn't abstract the totality of network, application, service to a broker and set contracts through the broker.   And I think given that this is a commercial service we HAVE to think about how people make money and how the transaction is settled including penalties for non-delivery against the SLA.    But we still hit the same anchored-architecture issues and that doesn't change in 5G because it is still the same technology as GPRS in the core.
> 
> To my mind if "6G" is anything it is the ability to stop thinking about the access method and start thinking about service delivery. 
> 
> BTW, I'm using my trivial music pursuits as an example - project this to the issue of real-time interactive education on-line and you can see why it is of societal interest (or at least should be IMvHO).
> 
> David
> 
> -----Original Message-----
> From: Toerless Eckert <[e-mail]> 
> Sent: 14 January 2021 18:49
> To: Lake, David (PG/R - Elec Electronic Eng) <[e-mail]>
> Cc: Alexandre Petrescu <[e-mail]>; Flinck, Hannu (Nokia - FI/Espoo) <[e-mail]>; [e-mail]
> Subject: Re: [6gip] 6G in 3GPP?
> 
> On Thu, Jan 14, 2021 at 09:31:35AM +0000, David Lake wrote:
>> I think we're WAY ahead of ourselves here.
>> Much like 5G is primarily a marketing term, 6G falls into the same bucket.
>> 
>> 5G has delivered a new air-interface (5GNR) and architectural developments in terms of functional placement.  Otherwise, it retains much of the basis of GPRS in terms of protocols and likewise it retains many of the problems of network delivery that we see in today's Internet.
> 
> More fundamentally, i have severe doubts that 3GPP has the expertise or desire to attempt to redefine the wired underlay where low latency is "created"/ They simply expect that to come from some "transport service", which AfAIK could either be delivered by IEEE, IETF or some other SDO (in a standard fashion).
> Given past decade history, my bet is on IEEE when it comes to managing wired latency, unless IETF wakes up to the challenge. Right now, DetNet is not really at the forefront of innovation, but rather at the knocklehead tailend of converting TSN into MPLS and considering IP en-passant. Which isn't meant to blame DetNet, but rather a matter of catchup from where IEEE is, and being limited in what it can do when it can not really redefine the IP protocol stack to better suit innovaive latency management goals.
> 
>> Please excuse the slight rant, but...
> 
> Great rant. Where where you when RFC8578 was baked ?
> 
> Would be lovely if detnet could consider working on an rfc8578bis to add even more (such as your) details of all those use-cases we can't built with IP today (i don't think section 2. captures what you described well, but check it out). I also remember use cases of large-scale venue audio distribution and accoustic beats if phase offsets couldn't be suynchronized to speed of sound in the air between speakers (theme parks or the like..).
> 
>> I think there ARE interesting things to consider in future networking/applications but I am not sure that an IETF WG (or even an IRTF RG) are the right place to do those 1) as IETF is concerned with interoperability of existing solutions and 2) IRTF works in more defined areas 3) IETF/IRTF seem not to be particularly commercially-minded (in terms of the economics of running a utility service).
> 
> I wish i could say you are too negative and that i have seen a lot of what i consider leading edge innovation to originate from IETF/IETF through work or tracking of areas such as Multicast, LISP or MPLS and autonomic networking,  but alas, it seems that especially these days, there is a lot more focus on rejection politics and less on innovative standards engineering in the areas that would need improvements to better manage latency at the network layer.
> 
> If IETF/IRTF goes back operating on innovative research and engineering principles that has marked most of its history, i think it would be the best place to create collaboration for research and later standardize these type of innovations. 
> 
>> Areas that I think we could consider:
>> 
>> 1) Non-IP protocol support; much of the Internet was predicated on a small number of long-lived, large-packet flows (e.g. small numbers of consumers watching videos) which is what we have for the most-part today.
> 
> At the risk of boring everyone through repetition (i think i haven't said this on this mailing list though): IP to me is like an ice-berg: 90% of its deployments are below the water line in what we used to call controlled networks, and what rfc8799 now calls "limited domains". Only 10% is "the Internet". SRv6 in a service provider is for example a limited domain, as is any IP residential access into an SP.  The Internet is just one of many  services tunneled across it.
> 
> When i get "Internet access" today at an SP that comes with IP Multicast IPTV, that particular service itself is not part of "The Internet" service i get. Its just multiplexed into my Internet service through the same instance of IP. In the same way i could multiplex future better latency managed services into what then still looks like the same old "Internet"
> service to the subscriber.
> 
> Aka: IP (NOT THE INTERNET) IMHO would be perfectly capable to be expanded into what i think we would need to better manage latency. IMHO, we just need to think beyond rfc8200, in the same way we would have needed to think beyond rfc8200 if lets say IP multicast wouldn't have been invented before rfc8200.
> 
>> The ratio of header:payload works in terms of network/energy efficiency.  Move that to a landscape of IoT where the data comprises of small payload, short-lived but billions of devices and the question must be asked if the current header:payload ratio is appropriate.   There are then questions over energy efficiency and cost-per-bit of transport - where are the studies on that? 
> 
> Good question. I know IoT folks in the IETF complaining about the
> 1280 minimum MTU in IPv6 though as one random dat point.
> 
> IoT with IPv6 today lives primarily through a lot of header compression and state created for that compression. If we would get away from the mantra that all future addresses of record have to be 128 bit there would be a lot of more flexibility and simplification in the picture for IoT.
> 
>> 2) QoE. Predominantly, Telcos are becoming pipes to the application but remain disconnected from the notion of service delivery.   Likewise, the economic model does not work in the same way as any other supply chain and consequently incentives for good delivery are not built into the overall solution.   The only exception to this is VoLTE where the OTA numerology is tightly-coupled to the network and admission-control is exact.  However, consumers are moving away from operator-provided services. 
> 
> This is actually a core point: Service providers will only offer better than "Best Effort" IP services when they can figure out how to make more money from this. Beside VoLTE, IP Multicast for their own IPTV service is another example of how this mostly happens: primarily for application services owned by the SP. The exception to this rule are transport services such as L2VPN/L3VPN, where the QoE is not tied to an SP application service itself.
> 
>>  6G could address this to build a proper supply-chain and settlement system across both wired and wireline networks.  Currently, I have no SLA with any application and no ability to have one enforced yet I pay both the application provider AND the transport provider.  This is like buying a train ticket for a timed express service and being told "we don't know when you'll arrive or even if the train will run and you won't get your money back under any circumstances."
> 
> Yes. that's one option. I personally find the complexity of trying to persuade marketing people in service provider into introducing new QoE services into "network/transport" offerings and then succeed in wholesaling those - to be mindboggling.
> 
> IMHO the better approach is to focus on research into virtualizing the forwarding plane of interest such that it can be programmable by the actual customer. In the same way as 4G/5G cores are nowadays often only a bunch of VMs/containers in edge-DCs, the actual forwarding plane in metro-router/switches could become programmable to customers such as "advanced-QoE-slice-operators" that are also owning/developing the actual solutions/applications (such as interactive city-wide music).
> 
> Certainly, programmable forwarding plane to enable this, would today by a research, not a standardization yet, but i can not think of a better place to draw expertise from than IETF/IRTF to do this.
> 
>> 3) Consolidation of access.  Living where I do in the south-east of England, I have access to 4 MNOs all with good 4G service.  My parents-in-law live on the east coast of England with access to zero cellular networks (a village of 30 people means it is not cost-effective for all 4 to build so none do).   National roaming does not fix this problem.   They also get very poor DSL service which no planned upgrade.  Removing one MNO from me and placing it with them would make a massive difference to their lives and zero impact to mine but is commercially unacceptable.  But what is better for society in general?
> 
> AFAIK, there is a lot of work on "tower virtualization/sharing"
> 
>> None of these fall into the remit of an IETF or IRTF groups but I think would be far more valuable questions to ask at this point in the gestation of "6G."
> 
>> I'd be very happy to talk about these areas at the next 6GIP meeting.
> 
> Cheers
>    Toerless
> 
>> David
>> 
>> -----Original Message-----
>> From: 6gip <[e-mail]> On Behalf Of Alexandre Petrescu
>> Sent: 14 January 2021 08:45
>> To: Flinck, Hannu (Nokia - FI/Espoo) 
>> <[e-mail]>; [e-mail]
>> Subject: Re: [6gip] 6G in 3GPP?
>> 
>> Le 13/01/2021 à 16:57, Flinck, Hannu (Nokia - FI/Espoo) a écrit :
>>> Hello
>>> 
>>> Neither I know any, nor my colleagues any 3GPP documents about 6G.
>>> 
>>> 3GPP is currently at mid-way with 5G. There will still be a number 
>>> of releases left for 5G  to come. In fact, I assume that now when 5G 
>>> is pushing towards new verticals (mIoT, industry, vehicular, etc.) 
>>> there will be new requirements for protocol work needed for 5G. For 
>>> example, consider the discussion about multi-path support for QUIC in QUIC wg.
>>> Similar requests are likely to come.
>> 
>> Hannu,
>> 
>> I do not disagree.
>> 
>> I think indeed 3GPP still works a lot on 5G.  I think it is good they do it.  I think 3GPP might not need an email list at IETF to design use-cases for 5G and 5G+ of 3GPP.
>> 
>> That is a personal oppinion and represents just one person.
>> 
>>> Therefore, I am on the opinion that 6G work, even 6G related 
>>> protocol research work in the IRTF, should wait for use cases (and 
>>> radio
>>> extensions) that 5G is not able to respond.
>> 
>> I dont think so.
>> 
>> I think 5G work at 3GPP is great.
>> 
>> Would your suggestion be that 6gip email list should wait for 3GPP to work on 6G?
>> 
>> There might be a problem with names, but I doubt 3GPP has a trademaark on an acronym such as "6G".  "5G" itself was in years 1980 representing the 5th Generation of Computers.  People also use routinely the term "5G" to stand for 5 Gigahertz instead of the 5th Generation of telecom.
>> 
>> Alex
>> 
>>> 
>>> 
>>> Best regards Hannu
>>> 
>>> -----Original Message----- From: Alexandre Petrescu 
>>> <[e-mail]> Sent: Wednesday, January 13, 2021
>>> 10:40 AM To: Flinck, Hannu (Nokia - FI/Espoo) 
>>> <[e-mail]>; [e-mail] Subject: Re: 6G in 
>>> 3GPP?
>>> 
>>> Me too I would like to ask I would like whether someone knows of a 
>>> document on the 3gpp.org site that has the term '6G' in it?
>>> 
>>> Le 12/01/2021 à 17:55, Flinck, Hannu (Nokia - FI/Espoo) a écrit :
>>>> Hello Alexandre
>>>> 
>>>> In your slides you claim the 6G is discussed in Rel 17. Can you 
>>>> tell in which document or WG?
>>>> 
>>>> I am involved quite a bit in 3GPP as well as in 6G research and I 
>>>> am not aware of any of such discussion.
>>>> 
>>>> Without a reference I must consider that statement be misinformation.
>>>> 
>>>> Best regards
>>>> 
>>>> Hannu
>>> 
>>> Thanks for having gone through the slides; the slides tried to 
>>> summarize the discussions on the email list at that time.
>>> 
>>> It might be that a potential reationship between 3GPP and 6G to be a 
>>> stretch.
>>> 
>>> I might bear responsibility of having misread the emails, or read 
>>> them too quickly, when drawing a conclusion that 3GPP might work on 
>>> 6G, and writing that down.  Sorry for misunderstanding.
>>> 
>>> We had some mention on this list of an NGMN alliance (Next 
>>> Generation Mobile Networks) which initiated a task force on 6G; 
>>> elsewhere, NGMN is ack'ed as a contributor to 3GPP by a wikipedia 
>>> article.  That might make it that 3GPP might have some work on 6G.
>>> 
>>> It might be that some discussions between usual contributors to 3GPP 
>>> might have mentioned 6G even though there might be no document on 
>>> 3gpp.org that reads '6G'.  For my part, I do not know what document 
>>> is Rel 17 more precisely, but I suspect I could find Rel 17 on 3gpp.org.
>>> 
>>> It might be that other industry alliances (e.g. 5GAA) could be 
>>> outright opposed to work on things deemed "6G".  It might be that 
>>> such opposition is supported by other funding bodies.  I do not know 
>>> why the opposition, but that is the way it is.
>>> 
>>> If, for some reason, 3GPP considers the talk of 6G to be too early, 
>>> and why not potentially disruptive to the ongoing work of 5G, then 
>>> that is a 3GPP problem to solve.  That would not be the only problem 
>>> they should address.  I suspect a ling standing problem is even the 
>>> name "3G" in a 3GPP working on something else than 3G (e.g. 3GPP 
>>> working on 4G or 5G).
>>> 
>>> I want to tell also that there might be other problems of 5G, on 
>>> which 3GPP works, and which deserve attention.
>>> 
>>> Such problems could be solved by working on something new, like 6G.
>>> 
>>> It is a speculation from my part.
>>> 
>>> I would like to ask others whether someone knows of a document on 
>>> the 3gpp.org site that has the term '6G' in it?
>>> 
>>> Alex
>>> 
>> 
>> --
>> 6gip mailing list
>> [e-mail]
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> ietf.org%2Fmailman%2Flistinfo%2F6gip&amp;data=04%7C01%7Cd.lake%40surre
>> y.ac.uk%7Ca3cd5fe4075e416ff7ea08d8b8bd18a6%7C6b902693107440aa9e21d8944
>> 6a2ebb5%7C0%7C0%7C637462469605680996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
>> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
>> data=QxWzKRpbv9dBLuZHYHBHEfRNBoAc%2FyA6496ZaA75ujw%3D&amp;reserved=0
>> 
>> --
>> 6gip mailing list
>> [e-mail]
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> ietf.org%2Fmailman%2Flistinfo%2F6gip&amp;data=04%7C01%7Cd.lake%40surre
>> y.ac.uk%7Ca3cd5fe4075e416ff7ea08d8b8bd18a6%7C6b902693107440aa9e21d8944
>> 6a2ebb5%7C0%7C0%7C637462469605680996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
>> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
>> data=QxWzKRpbv9dBLuZHYHBHEfRNBoAc%2FyA6496ZaA75ujw%3D&amp;reserved=0
> 
> --
> ---
> [e-mail]
> 
> -- 
> 6gip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6gip