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

[Toerless Eckert <[e-mail]>]

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%40surrey.ac.uk%7Ca9948f6b27da441019bc08d8b868bfc7%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637462107334487697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=zCyHLsSxDHArH47eWOnMY4JkKBZxN9OaQO2t0KMnirw%3D&amp;reserved=0
> 
> -- 
> 6gip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6gip

-- 
---
[e-mail]