[multipathtcp] rfc6824bis discussion about 5G session continuity support

Xavier de Foy <x.defoy.ietf@gmail.com> Mon, 30 July 2018 19:03 UTC

Return-Path: <x.defoy.ietf@gmail.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C5401130EAE for <multipathtcp@ietfa.amsl.com>; Mon, 30 Jul 2018 12:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id c1onZkENwEa6 for <multipathtcp@ietfa.amsl.com>; Mon, 30 Jul 2018 12:03:29 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4FB130EA9 for <multipathtcp@ietf.org>; Mon, 30 Jul 2018 12:03:29 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id a5-v6so13287260qtp.2 for <multipathtcp@ietf.org>; Mon, 30 Jul 2018 12:03:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=G/fnMJQ4cz8gX+siZvkMEEH6E+VcCI1d0uXxxx3r7/A=; b=VQKtMiV6F0L9ICeclmOp2OH0Gmru35YnJBNYtSkWMvyqq24FgIQNQovWNhJxhjc5vt 3wkazgQ49zy4FusdzpoMYzrVFvBd5zBjImw3H7Ly5M73I7ubPLnv8BI6O8xnVTotc0+h CLH9/WNz1pZStGM7vXRFRhwnPl/o4dqKdtW5JJfgfOsOP+XJ8IOq9slRJ1xe7r5oa8U9 RM/TkzKkF4tvYxOOzjV7W2nT8eFvl++/sgADwi7eynzoAbEaj11fqHAe3NQJRTPYDFB6 1KiUZg0GAN/bPMWr2rg1Rct9tUeRpTbkpN368InM4AOMS1PL7eeg8DKT3AFbK/xvrFF/ LViQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=G/fnMJQ4cz8gX+siZvkMEEH6E+VcCI1d0uXxxx3r7/A=; b=CiZUpxpHephC0Mu2BS7EzMeXxym8sMy44isNyM17eCdfj1KQzEfhW7q31M7/uIczg/ vrBAvzPSLJNIY03QvK4NzbSLZ8GkSCnHRpOV517U0zKcb5G9SrSyfW4QTE3ChTJkN/Lr FyMb4Ad3CEaO+9i3yz8+A8p9boOEVIZHOIQoxof5TLOoFHPUvi9lj8lXMtZPlJ1QCSk9 MfCXLgxJiN3oinhNkw9V7gzVdCW+zC7xS6pdxMQYfBRy5rPrlzlYxm2T9hXBXiB+QNvI E4CczZdTdqVHr6DqsXwlCj7zWagMYTmg23rk7ZefeihdChr8FMqi2QC7HYbG35J4hME9 kYKA==
X-Gm-Message-State: AOUpUlHwxAk+xX9lHH+Wr6pRxyB6UmEQWtiZlJ2+U0rFkImkxGEyepQD NwEAdL2j0sUDkFvfBbM7GS48ZjLdW3t9FZfNweFWR/Js
X-Google-Smtp-Source: AAOMgpdlLaoas3faObl5rFwf/Gz6ztSPs3YNFXFBEQgeDFTNYDzrT6/2f8iFWwRFSxztnjvu4bb86ilcONwnQU8LTmc=
X-Received: by 2002:ac8:4402:: with SMTP id j2-v6mr17960835qtn.233.1532977408278; Mon, 30 Jul 2018 12:03:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:2ea2:0:0:0:0:0 with HTTP; Mon, 30 Jul 2018 12:03:27 -0700 (PDT)
From: Xavier de Foy <x.defoy.ietf@gmail.com>
Date: Mon, 30 Jul 2018 15:03:27 -0400
Message-ID: <CAHYjOTY23yOojHt+tYNYBJKxakRrFpLxuwsBBkDbVoW5F2F0fA@mail.gmail.com>
To: multipathtcp <multipathtcp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000de854005723c1d3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/GHWlOJnfSg2gGoVyr1BSXufM8dI>
Subject: [multipathtcp] rfc6824bis discussion about 5G session continuity support
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2018 19:03:32 -0000


As promised during the MPTCP meeting session at IETF 102, here is a summary
of our findings related to 5G session continuity support, as part of the
review of rfc6824bis.

The root problem is the following: in 5G, a client may have IP addresses
provided by a mobile network, in association with a session continuity
service (SCC mode 1/fixed, 2/distributed anchor + BBM or 3/ distributed
anchor + MBB). Such an IP address can be replaced, or be complemented with,
another IP address, possibly multiple times during the lifetime of an
application session. If the MPTCP stack is not aware of this, it can’t make
the link between these addresses, and can’t make the correct or most
efficient decisions in some cases.

I think there is at least a case for _local_ usage of session continuity
information by the 5G device MPTCP stack.  Every new IP address can
(locally) be associated with a tuple (address type, original IP address),
using the DMM-defined “address types” which have a 1:1 relationship with
the 3GPP SCC modes. For example, using this information, a MPTCP local
stack can copy the backup priority property from one IP address to the next
when appropriate.

**Rationale to send new information over MPTCP (and workarounds) **

In addition to the local usage of this information, here are possible
scenarios where sending the tuple (address type, original IP address ID)
over MPTCP signaling may help the remote peer making appropriate decisions:

Case #1: the IP address in active use is over SSC mode 3/MBB, and there is
a MBB handover:

- We want both MPTCP peers to start using new path(s) using the new IP
address, then wait for its bandwidth usage to ramp up, and, after some
time, cleanly remove the old IP address (cleanly = not losing/re-sending
packets). This is for a smooth transition in term of performance, and to
release network resources associated with the old IP address. If both peers
have access to the tuple (address type, original IP address), they can both
perform these actions. After a while, one side can close the now unused
subflow(s), and then remove the IP address.

- Possible workaround/solution: there is no need to send the tuple over
MPTCP signaling, if the MPTCP client has the possibility to request a clean
shutdown of old paths/addresses. When discussing this with Christoph, he
proposed a quick way to implement a clean shutdown, if I recall correctly:
(1) set the priority of subflows using this address to “backup”, (2) wait
for in-flight TCP segments to arrive and be acked, (3) remove the IP
address. See below in conclusion for additional details on this.

Case #2: on the client, the IP address in active use is over SSC mode
2/BBM, and there is another backup IP address:

- If no change is made, during the break before make, the peers will switch
to use the backup IP address. This may not be the desired outcome (e.g.
waking up a radio for a few packets, and changing the properties of the
path for a very short period of time). Sending the tuple (address type,
original IP address) as above enables avoiding this situation.

- Possible workaround/solution: in 5G systems, it may be possible to avoid
using SSC mode 2/BBM for applications that use MPTCP, by adjusting SSC
policies for those applications. (At this time it is not clear if will be
possible in all cases, e.g. applications may also request a specific
continuity service using setsc().)


A long term solution for cases #1, #2, and possibly other scenarios that
may emerge later, could be to send a tuple (address type, original IP
address ID) to the remote peer, over MPTCP. This information would be
associated with options that can introduce a new IP address, like ADD_ADDR,
MP_JOIN, MP_CAPABLE. Nevertheless, experiments will be needed to determine
if it is really needed, or if a local usage of this information on the
client side is enough. Since 5G deployments are not yet common, it will
take time. Thus it may be best to rely on the experimental extension
mechanism, and possibly make sure some minimal support is in place in


(1) Document, in rfc6824bis, a “clean remove” of a live address – this will
enable dealing with the most obvious case #1 (SSC mode 3).

- Basically, this can use the mechanism described above. Either now or in a
future version of the protocol, it could make sense to avoid corner cases
(e.g. use a new “inactive” priority for subflows, and possibly a new reason
code “inactive address” when closing the subflows).

(2) Could we make sure that experimental extensions are available in the
new version of the MPTCP protocol?

- Additional question: do you think it will be acceptable to mandate
sending an extension option within the same packet as another MPTCP option?
It would be convenient to place the address type extension within the same
packet used to transmit the option it extends (e.g. ADD_ADDR, MP_JOIN,
MP_CAPABLE). This would ensure that there is no sync issue between them,
due to timing issue or packet loss, and there will be no need to explicitly
deal with re-transmission of this particular extension option.

Best Regards,