[multipathtcp] rfc6824bis discussion about 5G session continuity support

[Xavier de Foy <[e-mail]>]

Hi,

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





**Conclusion**



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
rfc6824bis.



Proposal:



(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,



Xavier.