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

Marco Liebsch <Marco.Liebsch@neclab.eu> Thu, 30 March 2023 16:04 UTC

Return-Path: <Marco.Liebsch@neclab.eu>
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 E0456C15EB2E for <dmm@ietfa.amsl.com>; Thu, 30 Mar 2023 09:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham 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 iWIy9GgByUUg for <dmm@ietfa.amsl.com>; Thu, 30 Mar 2023 09:04:41 -0700 (PDT)
Received: from mailer2.neclab.eu (mailer2.neclab.eu [195.37.70.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3FDC15C520 for <dmm@ietf.org>; Thu, 30 Mar 2023 09:04:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer2.neclab.eu (Postfix) with ESMTP id 04FEC7A0DEE; Thu, 30 Mar 2023 17:58:54 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux ()
Received: from mailer2.neclab.eu ([127.0.0.1]) by localhost (atlas-b.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBPZYg6TOwSb; Thu, 30 Mar 2023 17:58:53 +0200 (CEST)
Received: from Oberon.office.hd (Oberon.office.hd [192.168.24.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailer2.neclab.eu (Postfix) with ESMTPS id D846D7A0B83; Thu, 30 Mar 2023 17:58:53 +0200 (CEST)
Received: from puck.office.hd (192.168.24.91) by Oberon.office.hd (192.168.24.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 30 Mar 2023 17:58:53 +0200
Received: from puck.office.hd ([192.168.126.12]) by puck.office.hd ([192.168.126.12]) with mapi id 15.01.2507.023; Thu, 30 Mar 2023 17:58:53 +0200
From: Marco Liebsch <Marco.Liebsch@neclab.eu>
To: David Lake <d.lake=40surrey.ac.uk@dmarc.ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: Comments on "Mobile traffic steering"
Thread-Index: AQHZYElWMOcxpGwhTUO+Ds+790zKNa8TeGUg
Date: Thu, 30 Mar 2023 15:58:53 +0000
Message-ID: <803207ae090444469c7c3532e7ab3496@neclab.eu>
References: <DBAPR06MB685561321E67D2A45C4ED25AB58B9@DBAPR06MB6855.eurprd06.prod.outlook.com>
In-Reply-To: <DBAPR06MB685561321E67D2A45C4ED25AB58B9@DBAPR06MB6855.eurprd06.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.24.96]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0014_01D96331.463DC1A0"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/Mj6QcPxDTTcKi1-OWGGgwYtAkB4>
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: Thu, 30 Mar 2023 16:04:44 -0000

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.

 

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

 

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.

 

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