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

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

Thanks Christoph,

On Wed, Aug 1, 2018 at 1:44 PM, Christoph Paasch <[e-mail]> wrote:

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

[xdf] agreed. Having a finite latency parameter (instead of an "inactive
priority", which would be equivalent to an infinite latency) would help
handling cases where the BBM handover fails. It could also be used as a
priority mechanism between multiple backup subflows.


> > 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.
>
> [xdf] Yes, the solution should be as general as possible. By the way, the
address types are DMM-specific, not 5G-specific, so maybe it's less of a
problem.

So far, the problem to solve is that "session continuity" supporting
addresses behave as a single "logical address" that evolves over time
(sometimes with a break, sometimes with an overlap, and sometimes with an
additional temporary address). So using session-continuity specific
parameters may be acceptable (although I agree it's possible MPTCP will
only need more general mechanisms, in which case session-continuity
specific mechanics will only be implemented on the client side).



> > 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
> (?).
>
> [xdf] It could be a good work item (session continuity support could be a
use case of a more general problem).

Btw, I hope that the rfc6824bis authors will consider the proposal below
("clean remove" documentation and support for extension). This would make
it easier to experiment as part of the work item, in the future. The impact
is minimal: proposal (1) does not require any change in the protocol, just
document a practice, and proposal (2) is just to clarify what's happening
with extensions.

Xavier.


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