Re: [multipathtcp] rfc6824bis discussion about 5G session continuity support

[Christoph Paasch <[e-mail]>]

Hello,

On 30/07/18 - 15:03:27, Xavier de Foy wrote:
> 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).

This here would basically mean that we want to add an additional "latency"
to the backup-bit information. This latency would mean that even if there
are no other paths available, a host should wait a bit more before sending
on the subflow marked as backup.

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

I think we should avoid exposing 5G-specific information in MPTCP and (if
really needed) rather abstract those mechanics away into a more generic
format.

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

It seems to me that those 5G constructs could be expressed in generic
scheduling policies. In general, this is currently a missing piece in MPTCP.
In the sense that a client connecting to a server has no fine-grained
control over how the server is scheduling data. With today's special purpose
deployments (where clients know exactly what server they are connecting to),
it's not a big problem. But for a more generic deployment of MPTCP it would
be useful to allow more fine-grained control.

Maybe that would be a good work-item for the working-group's next steps (?).


Christoph

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

> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp