[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

MPTCP Working Group                                              V. Tran
Internet-Draft                                            O. Bonaventure
Intended status: Informational          Universite catholique de Louvain
Expires: January 9, 2020                                   July 08, 2019

                  Multipath TCP Inactivity Time Option


   This document discusses the lifetime of idle MPTCP sessions, and
   defines an MPTCP Option subkind for hosts to announce and request
   this value.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 9, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Tran & Bonaventure       Expires January 9, 2020                [Page 1]

Internet-Draft            mptcp-inactivity-time                July 2019

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Lifetime of Multipath TCP connections . . . . . . . . . . . .   3
   4.  The Multipath TCP Inactivity Timer Option . . . . . . . . . .   4
     4.1.  Option Format . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  ITO Option and Local Policies . . . . . . . . . . . . . .   5
   5.  Implementation and Interoperability . . . . . . . . . . . . .   5
     5.1.  Interaction with TCP Keepalives . . . . . . . . . . . . .   5
     5.2.  Interaction with User Timeout . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Multipath TCP [RFC6824] [I-D.ietf-mptcp-rfc6824bis] is used in
   various use cases [RFC8040].  In several of these deployments, a
   Multipath TCP connection is composed of a number of subflows that
   varies during the lifetime of the connection.  TCP implementations
   create state when a connection starts and maintain this state until
   the abrupt or graceful termination of the connection according to the
   TCP state machine [RFC0793].  Multipath TCP implementations need to
   maintain two types of states:

   o  the per-Multipath TCP connection state that includes the
      connection keys, data sequence numbers, ...

   o  the per-TCP subflows connection states

   The per-TCP state of each subflow is managed according to [RFC0793].
   The Multipath TCP connection state also needs to be managed.  We
   consider a subflow to be active if its TCP state machine exists and
   is in the Established state.  We call inactive a Multipath TCP
   connection that currently has no active subflow.  It is important to
   note that it is possible for one host to consider a given Multipath
   TCP connection to be inactive while the other endpoint considers that
   the connection is still active.  This can happen for example when
   some packets are lost or when one of the hosts has received a
   spurious RST on the only active subflow.  [RFC6824] and
   [I-D.ietf-mptcp-rfc6824bis] specify how this state can be removed
   upon transmission or reception of a FASTCLOSE and after having
   exchanged DATA_FINs.  However, [RFC6824] and

Tran & Bonaventure       Expires January 9, 2020                [Page 2]

Internet-Draft            mptcp-inactivity-time                July 2019

   [I-D.ietf-mptcp-rfc6824bis] do not specify precisely how the
   Multipath TCP connection state must be managed when all the TCP
   subflows associated with this Multipath TCP connection have been
   released.  A similar problem existed in TCP for idle connections.  It
   was clarified in [RFC1122].

   Given the cost of maintaining state for inactive Multipath TCP
   connections, hosts may want to limit the time during which they
   maintain state for inactive Multipath TCP connections.  Neither
   [RFC6824] nor [I-D.ietf-mptcp-rfc6824bis] propose a default duration
   to maintain this state.  Although some applications such as http/1.1
   include a mechanism to terminate idle connections, many applications
   do not do this.  We fill this gap in this document and propose a
   Multipath TCP option that enables hosts to agree on a common minimum
   duration to maintain inactive Multipath TCP connections.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119

3.  Lifetime of Multipath TCP connections

   A Multipath TCP connection starts with a three-way-handshake that
   uses the MP_CAPABLE option and ends with either the transmission of
   DATA_FINs or a FASTCLOSE.  Between these two events, the number of
   subflows that compose the connection may vary and during some periods
   of time, it is possible that no active subflow is associated with an
   existing Multipath TCP connection.

   There are several types of events which can occur during the lifetime
   of a Multipath TCP connection:

   o  establishment of a new subflow

   o  graceful termination of subflow with the exchange of FINs

   o  abrupt termination of a subflow due to multiple expirations of its
      retransmission timer, the reception of a RST or an abnormal
      packet, ...

   To support the establishment of a new subflow with the MP_JOIN
   option, a host must maintain state for all established Multipath TCP
   connection.  Neither [RFC6824] nor [I-D.ietf-mptcp-rfc6824bis]
   specify how a host should behave upon (graceful or abrupt)
   termination of the last subflow associated with an existing Multipath

Tran & Bonaventure       Expires January 9, 2020                [Page 3]

Internet-Draft            mptcp-inactivity-time                July 2019

   TCP connection.  One possibility would be to consider that since no
   subflow is associated with this connection, its state could be freed.
   A consequence of this policy is that it would then be impossible to
   establish a new subflow to this connection to recover from the
   failure of the previous one.  Another possibility is to preserve the
   state of this Multipath TCP connection for some period of time.  This
   would better match the expectations of mobile use cases where
   subflows can fail abruptly when devices move.

   This document proposes the utilisation of an Inactivity timer in
   Multipath TCP implementations.  This timer bounds the time during
   which there is no active subflow associated with a given Multipath
   TCP connection.  It starts when the last active subflow associated
   with a connection is terminated.  It is reset when one active subflow
   is associated with this Multipath TCP connection.  Upon expiration of
   this timer, the host SHOULD remove state for the associated Multipath
   TCP connection.  If a host wants to maintain a Multipath TCP
   connection as active, it SHOULD try to reestablish a subflow
   associated with this Multipath TCP connection before the expiration
   of its inactivity timer.  This document suggests implementations to
   start the reestablishment of such a subflow after half the Inactivity

4.  The Multipath TCP Inactivity Timer Option

   The Multipath TCP Inactivity Timer Option (MPTCP ITO) is used to
   exchange the Inactivity Timer associated with this connection.  This
   documents recommends a default value of 2 hours and 4 minutes - the
   same as default NAT timeout as discussed in [RFC5382].  The reason
   for this value is to allow the peer with default keepalive timer of 2
   hours ([RFC1122]) to probe successfully.

4.1.  Option Format

   The format of the ITO option is depicted in Fig. Figure 1:

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |     Kind      |  Length = 5   |Subtype| (rsv) |   Inactivity  |
      |     Timer     |

              Figure 1: MPTCP Inactivity Timer Option Format

Tran & Bonaventure       Expires January 9, 2020                [Page 4]

Internet-Draft            mptcp-inactivity-time                July 2019

   In the ITO option, the Inactivity Timer (16 bits) specifies the
   requested Timer for the MPTCP session in seconds.  A value of zero
   indicates that the state for the Multipath TCP connection will be
   removed as soon as there is no active subflow.

4.2.  ITO Option and Local Policies

   The ITO option is used to specify the value of the Inactivity timer
   associated with the connection by the host that sends the option.
   Upon reception of this option, the receiver SHOULD update its ITO
   option based on the ITO option received from its peer.  However, it
   MAY choose to apply and transmit its own ITO option, depending on its
   local policies.  Note that the ITO option is an indicative value.  A
   host may terminate long inactive connections before the expiration of
   the ITO timer due to the increasing memory resource pressure.

   Like all Multipath TCP options, the ITO Option is exchanged without
   any protection from TCP's reliability mechanisms.  Therefore,
   implementations MUST NOT assume that it is transferred reliably.
   Implementations that use the ITO option can transmit the ITO option
   at any time.  Since the utilisation of this option is not negotiated
   during the connection handshake, a host MUST NOT send more than three
   ITO options on a connection where it has not received any ITO option.

   After the expiration of the Inactivity timer, the host MAY choose to
   close the MPTCP session with MPTCP_RST and all of its subflows with
   TCP_RST, and report the inactivity timeout error to the user.  This
   is a common case on the servers that want to free the resource
   occupied by unused sessions as soon as possible so that they could
   serve other users.

5.  Implementation and Interoperability

5.1.  Interaction with TCP Keepalives

   The mechanism specified in this document operates above the TCP
   Keepalives defined in [RFC1122].  If TCP Keepalives are enabled on at
   least one of the subflows of a Multipath TCP connection, then this
   subflow will remain active and the Inactivity timer of the associated
   Multipath TCP connection will not expire.  In this case, the
   Inactivity timer should be longer than the TCP Keepalive timer.  If
   TCP Keepalives are disabled, then the mechanism described in this
   document will remove the state of the inactive connections.

   On some MPTCP implementations like Linux, the TCP Keepalive is
   supported at the MPTCP layer.  To implement the idle timeout option,
   these implementations may use the MPTCP KeepAliveTime value to keep
   track of the current idle time.  However, the idle timeout mechanism,

Tran & Bonaventure       Expires January 9, 2020                [Page 5]

Internet-Draft            mptcp-inactivity-time                July 2019

   when activated, should override the keepalive mechanism.  This means
   that after the idle timeout fired, the host should abort the
   connection instead of sending the TCP keepalives.

   The MPTCP Inactivity Timer Option MAY be controlled on a system-wide
   setting or on a per-connection basis.  Specific APIs and mechanisms
   for controlling the ITO option are out of the scope of this document.

5.2.  Interaction with User Timeout

   The interactions between the User Timeout option [RFC5482] and the
   ITO option will be discussed in a subsequent revision of this

6.  Security Considerations

   The ITO option enables hosts to exchange the value of a timer that
   protects against some types of ressource exhaustion attacks.
   Multipath TCP implementations should define a range of safe values
   for the ITO option and prevent applications from configuring an
   inactivity timer outside this range.  They should also ignore
   received ITO options that are outside this range.

   Since the ITO option is neither encrypted nor authenticated, on-path
   attackers and middleboxes could remove, add or modify the ITO option
   on observed Multipath TCP connections.

7.  IANA Considerations

   IANA is requested to assign an MPTCP option subtype for the ITO
   option from the "MPTCP Option Subtypes" available at

8.  Acknowledgements

   This work was supported by the ARC-SDN project and the Walinnov MQUIC
   project, No. 1810018.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

Tran & Bonaventure       Expires January 9, 2020                [Page 6]

Internet-Draft            mptcp-inactivity-time                July 2019

9.2.  Informative References

              Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
              Paasch, "TCP Extensions for Multipath Operation with
              Multiple Addresses", draft-ietf-mptcp-rfc6824bis-18 (work
              in progress), June 2019.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,

   [RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, DOI 10.17487/RFC5382, October 2008,

   [RFC5482]  Eggert, L. and F. Gont, "TCP User Timeout Option",
              RFC 5482, DOI 10.17487/RFC5482, March 2009,

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,

Authors' Addresses

   Viet-Hoang Tran
   Universite catholique de Louvain

   Email: hoang.tran@uclouvain.be

Tran & Bonaventure       Expires January 9, 2020                [Page 7]

Internet-Draft            mptcp-inactivity-time                July 2019

   Olivier Bonaventure
   Universite catholique de Louvain
   Pl. Ste Barbe, 2
   Louvain-la-Neuve  1348

   Email: olivier.bonaventure@uclouvain.be

Tran & Bonaventure       Expires January 9, 2020                [Page 8]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/