Re: [DMM] Comments on "Mobile traffic steering"

Tianji Jiang <tianjijiang@chinamobile.com> Fri, 14 April 2023 00:27 UTC

Return-Path: <tianjijiang@chinamobile.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4F2C13AE40 for <dmm@ietfa.amsl.com>; Thu, 13 Apr 2023 17:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.894
X-Spam-Level:
X-Spam-Status: No, score=-6.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aypVgaPBeZg for <dmm@ietfa.amsl.com>; Thu, 13 Apr 2023 17:27:21 -0700 (PDT)
Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 93B6BC13AE3F for <dmm@ietf.org>; Thu, 13 Apr 2023 17:27:16 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app11-12011 (RichMail) with SMTP id 2eeb64389de10e7-b9cc1; Fri, 14 Apr 2023 08:27:14 +0800 (CST)
X-RM-TRANSID: 2eeb64389de10e7-b9cc1
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from [192.168.86.28] (unknown[99.0.86.16]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee764389dd770a-7ce43; Fri, 14 Apr 2023 08:27:14 +0800 (CST)
X-RM-TRANSID: 2ee764389dd770a-7ce43
User-Agent: Microsoft-MacOutlook/10.10.1b.201012
Date: Thu, 13 Apr 2023 17:25:27 -0700
From: Tianji Jiang <tianjijiang@chinamobile.com>
To: David Lake <d.lake=40surrey.ac.uk@dmarc.ietf.org>, Marco Liebsch <Marco.Liebsch@neclab.eu>, "dmm@ietf.org" <dmm@ietf.org>
Message-ID: <52F8ECA4-3160-40EB-B0FC-5F3E0ABAE5E9@chinamobile.com>
Thread-Topic: [DMM] Comments on "Mobile traffic steering"
Mime-version: 1.0
Content-type: multipart/mixed; boundary="B_3764251543_1819680219"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/a64FsTPTHlXNxOoG0VhvMBWDYo0>
Subject: Re: [DMM] Comments on "Mobile traffic steering"
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Apr 2023 00:27:23 -0000

Marco:

 

Good day.

Very interesting work and indeed relevant to IETF DMM work – actually, IMO, it is not just for the future B5G/6G; rather, it is suitable for the current 5G-advance consideration.

 

I think the wide scope of the objective of achieving ‘end-to-end mobility traffic steering’ makes the work a little challenging; but, it was in the past, and now is not any more. Here is my reasoning, based on the 5G system:

 
The ‘end-to-end’ is comprised of UE, RAN-access, backhaul, 5G-core, N6 connectivity and DN. So, the mobile traffic steering would occur possibly at every location in the wireless domain (5GS) and also at the transport domain (DN).
The 5GS is like a transparent (composite) box to the (IP-domain) DN. The integration of the traffic routing policies of 5GS and DN is not straightforward. In one case like the N6-connectivity, the 5G-AF could be used for policy exchange & provisioning btwn 5GS and DN. But, the same mechanism might not work well for the steering @ UE, RAN-access, BH, etc. (which would require lots of normative work from 5GS PoV – IETF does not normally have this type of influential power, IMO.
But, I said above ‘now is not any more’. It is because of the near completion of the 5G-Adv (rel-18, stage-2). There are lots of enhancements to the 5GS. For example, in one of the KIs in (5G-Adv SA2) UPEO, it studies and standardizes ‘Whether and how the 5GC can be made aware whether or when the UE enforces a URSP rule to route an application traffic to a PDU Session based on the URSP rule provisioned by 5GC’. Clearly, the URSP rule could be modified upon AF’s request that could be further instructed by IP DN), which certainly bodes well for our IETF work.
Another example of ‘‘now is not any more’ is the CATS (Computing-Aware Traffic Steering) work we have been pushing forward. The IETF CATS WG was just formed recently and it had its 1st session in the past IETF-116. There are quite a few use cases in CATS drafts talking about how a ‘better’ traffic steering policy would benefit mobile services (over integral networks of both wireless and IP wireline).
 

And I am glad you mentioned the ‘sky case’ in the following email. I gave a preso regarding the on-going satellite projects in 3GPP in the satellite sidemeeting in the past IETF-116. There are clearly lots of challenges as we have to provide a truly global seamless network, spanning terrestrial, aerial and space. Evidently, to achieve optimal mobile traffic steering is a must, given such a dynamic & resource-constrained environment. 

 

So,  very exciting work and I would like to move forward together…

 

BR,

 

-Tianji

 

From: dmm <dmm-bounces@ietf.org> on behalf of David Lake <d.lake=40surrey.ac.uk@dmarc.ietf.org>
Date: Thursday, March 30, 2023 at 10:35 AM
To: Marco Liebsch <Marco.Liebsch@neclab.eu>, David Lake <d.lake=40surrey.ac.uk@dmarc.ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] Comments on "Mobile traffic steering"

 

Marco

 

A couple of comments <DL> in-line </DL> but this is exciting work and a very relevant topic where I believe IETF can define itself in 6G!

 

David

 

From: dmm <dmm-bounces@ietf.org> on behalf of Marco Liebsch <Marco.Liebsch@neclab.eu>
Date: Thursday, 30 March 2023 at 17:05
To: David Lake <d.lake=40surrey.ac.uk@dmarc.ietf.org>, dmm@ietf.org <dmm@ietf.org>
Subject: Re: [DMM] Comments on "Mobile traffic steering"

HI David,

many thanks for the positive and constructive feedback during the session and on the mailing list.

 

I agree with your view of how mobile communication systems evolved in the past and have several directions
in mind what and how it could be improved.

 

The point we wanted to make with this presentation and discussion is that for an evolution of how mobile communication 
ecosystems can/will be used, the end-to-end view is required. And today’s mobile communication systems don’t have all end-to-end
aspects in scope.

 

<DL> I think we need to investigate WHY the current systems don’t think ‘end-to-end’ as the Internet/IETF does and I suspect this will be as-much about economics and business models as it is about technical aspects.  It concerns me that the IETF has not been happy to think about the economics of networking in the past but the reality of cellular services is that this is VERY big business so the decisions that are made will be driven not by the best technical solution but by the ones that make regulatory and commercial sense.

 

If we are to be relevant as an SDO in 6G then we may need to start understanding (and influencing) the finances and governmental impact.  That maybe outside the scope of DMM but the IETF/IESG/IAB should have the ability to be engaged somewhere </DL>

 

The intention is to develop a view how IETF technology can complement any mobile communication system here with well-defined
interfaces for control, data plane and maybe even management.  The latter may also be useful if we consider steering traffic
across a single administrative domain. The good thing is that it does not conflict with any internals of a standardized mobile communication system,
whether it is based on any of the known SDOs or a WiFi enterprise network or... 

 

A fundamental starting point is to come up with a good set of use cases that benefit from the level of traffic steering we suggest.

These should include any more advanced scenarios, e.g. HAPs made out of non-terrestrial networked components, such as LEO satellites,
drones, whatever. Having a non-stationary or not-always-present network where nodes may move or disappear from the sky for
movement, energy, or failure reasons, we may want to mitigate such impact to existing data sessions. A HAP may for example have
a mobility anchor on-board to access a platform and its services. Steering of session’s traffic between such nodes is required in
case of topological changes, not because of end-device mobility but mobility of network nodes and service platforms.

This is just one example taken out of the sky .. ;-)

 

<DL> The same principles can apply to adjacent terrestrial networks and are a real ‘pain point’ for rural communities who are served by one (or less!) cellular operators.  We may want to reconsider the whole notion of a user being ‘owned’ by one operator at-all – we don’t have that concept in IETF because we’re disaggregated application and connectivity so that I can move ‘last mile’ provider without impacting the application.  </DL>

 

The same requirement may apply to more traditional systems and use cases, as we brought during the DMM session.

We think this could be a starting point, also to argue why some level of continuity on L3 may be useful. Then look at the different aspects

of connecting and inter-working with any mobile communication system as sketched on the last slide of my presentation deck.

 

<DL> There has been a discussion on the 6gip mailing list around ‘things that don’t work’ on today’s networks and whilst it isn’t a list of use-cases, I think it can be broadly summarized as ‘the networks exist as separate entities that the applications have to work AROUND rather than WITH.’ </DL>

 

 

Looking forward to jointly moving this ahead.

 

marco 

 

 

From: dmm <dmm-bounces@ietf.org> On Behalf Of David Lake
Sent: Montag, 27. März 2023 03:29
To: dmm@ietf.org
Subject: [DMM] Comments on "Mobile traffic steering"

 

Hi Marco

 

Thank you for the very interesting presentation.

 

There has been some parallel discussion on this in the 6gip mailing list and I think there is good work to do here.

 

My concern is that the current mobility solution in 3GPP is essentially inherited from GPRS and is more about L2 tunnels that true IP connectivity.   Many user applications are able to work across current network irrespective of the underlying ‘bit pipe’ – I am currently able to watch videos, make WhatsApp and iMessage calls on my end device no matter which network I am connected to whether local cellular or IETF WiFI.

 

By contrast, if I want to use the native dialer on my iPhone when roaming (which is normally VoLTE when at home on Vodafone UK), I am not able despite Vodafone UK operating an ePDG for VoWiFi.  Instead, they actively look to see if I have roamed out of country and then ONLY allow me to a local carrier and expensive roaming for SMS and voice.

 

If I were to be in the US, then with 2G/3G sunset, I would not be able to make any calls or SMS on the native iPhone app but OTT applications would work perfectly…

 

My point is whether we, as IETF, need to concern ourselves at all with the internal workings of the 3GPP networks because OTT applications seem to work irrespective of what network provider they are connected to.   It is only when I try and use the operator’s own services that I seem to run into trouble!

 

I think there would be value in being able to tie the quality of outcome in service (e.g. QCI, 5QI) of my OTT application if I am using an LTE/5GNR bearer – for example, in the same way that VoLTE media is steered to a dedicated bearer, why can’t WhatsApp or Facetime media ALSO be steered to a dedicated bearer?

 

Very happy to work on this!

 

David Lake

 

Tel: +44 (0)7711 736784

5G & 6G Innovation Centres

Institute for Communication Systems (ICS)
University of Surrey
Guildford
GU2 7XH

 

_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm