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

Versions: 00

MPTCP Working Group                                           F. Duchene
Internet-Draft                                            O. Bonaventure
Intended status: Experimental                                  UCLouvain
Expires: January 9, 2017                                   July 08, 2016


                  Multipath TCP Address Advertisement
                    draft-duchene-mptcp-add-addr-00

Abstract

   Multipath TCP [RFC6824] defines the ADD_ADDR option that allows a
   host to announce its addresses to the remote host.  In this document
   we propose some improvements to this mechanism.

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 http://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, 2017.

Copyright Notice

   Copyright (c) 2016 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
   (http://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.





Duchene & Bonaventure    Expires January 9, 2017                [Page 1]


Internet-Draft                 MPTCP ADDR                      July 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Proposed ADD_ADDR option  . . . . . . . . . . . . . . . . . .   4
     2.1.  Reliability . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Backup  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Priorities  . . . . . . . . . . . . . . . . . . . . . . .   7
     2.4.  Path diversity  . . . . . . . . . . . . . . . . . . . . .   9
     2.5.  Load balancing  . . . . . . . . . . . . . . . . . . . . .  10
   3.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  11
   4.  Security considerations . . . . . . . . . . . . . . . . . . .  11
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  12
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Multipath TCP is an extension to TCP [RFC0793] that was specified in
   [RFC6824].  Multipath TCP allows hosts to use multiple paths to send
   and receive the data belonging to one connection.  For this, a
   Multipath TCP is composed of several TCP connections that are called
   subflows.  [RFC6824] defines two options to manage the host
   addresses:

   o  ADD_ADDR is used to announce one address bound to a host (possibly
      combined with a port number)

   o  REMOVE_ADDR is used to indicate that an address previously
      attached to a host is not anymore attached to this host

   To cope with Network Address Translation (NAT), the ADD_ADDR and
   REMOVE_ADDR options contain an address identifier encoded as an 8
   bits integer.

   When the initial subflow is created, it is assumed to be initiated
   from the address of the client whose identifier is 0 towards the
   address of the server whose identifier is also 0.  Both the client
   and the server can use ADD_ADDR to advertise the other addresses that
   they use.  When an additional subflow is created, the MP_JOIN option
   placed in the SYN (resp.  SYN+ACK) contains the identifier of the
   address used to create (resp. accept) the subflow.

   The latest Multipath TCP draft [I-D.ietf-mptcp-rfc6824bis] defines
   the ADD_ADDR option as shown in Figure 1.





Duchene & Bonaventure    Expires January 9, 2017                [Page 2]


Internet-Draft                 MPTCP ADDR                      July 2016


                        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    |Subtype|(resvd)|  Address ID   |
   +---------------+---------------+-------+-------+---------------+
   |          Address (IPv4 - 4 octets / IPv6 - 16 octets)         |
   +-------------------------------+-------------------------------+
   |   Port (2 octets, optional)   |                               |
   +-------------------------------+                               |
   |                      Truncated HMAC (8 octets)                |
   |                               +-------------------------------+
   |                               |
   +-------------------------------+


            Figure 1: The Multipath TCP ADD_ADDR option format

   In this document, we propose to slightly modify the format of this
   option based on issues that have been detected while working with the
   Multipath TCP implementation in the Linux kernel.  More precisely, we
   address four different problems.  The first, discussed in
   Section 2.1, is that the ADD_ADDR option is sent unreliably.  This
   implies that the host sending an ADD_ADDR option cannot be sure that
   the address that it has advertised has been learned by the distant
   host.  The second issue, discussed in Section 2.2 is the handling of
   backup subflows.  Multipath TCP supports the creation of backup
   subflows through the B bit in the MP_JOIN option.  These backup
   subflows consume energy and radio ressources on mobile devices and it
   would be useful for a host to be able to advertise a backup address
   that would be used to create subflows after a failure.  The third
   issue is that multihomed hosts may have preferences on the
   utilisation of some of their addresses/interfaces to create
   additional subflows.  Section 2.3 proposes a priority field that
   allows them to advertise these preferences.  The fourth issue is that
   multihomed hosts, especially with IPv6, often have several addresses
   assigned to each interface.  In this case, it can be difficult to
   establish disjoint paths between the communicating hosts.
   Section 2.4 proposes a community field in the ADD_ADDR option to
   indicate that some addresses share the same path.  The last issue,
   discussed in Section 2.5 is that some hosts, e.g.  servers behind a
   load balancer or clients behind a firewall, may want to indicate that
   the address used for the initial subflow should not be used to create
   additional ones.








Duchene & Bonaventure    Expires January 9, 2017                [Page 3]


Internet-Draft                 MPTCP ADDR                      July 2016


2.  Proposed ADD_ADDR option

   To cope with the issues described later in this document we propose a
   new format for this option.  The format for this new option is shown
   in Figure 2.

                        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    |Subtype|E|(rsv)|  Address ID   |
   +---------------+---------------+-------+-------+---------------+
   |          Address (IPv4 - 4 octets / IPv6 - 16 octets)         |
   +---------------+---------------+---------------+---------------+
   | Commu |prio |B|   Port (2 octets, optional)   |               |
   +---------------+---------------+---------------+               |
   |                                                               |
   |               Truncated HMAC (8 octets)       +---------------+
   |                                               |
   +-----------------------------------------------+

      Figure 2: The proposed Multipath TCP new ADD_ADDR option format

2.1.  Reliability

   A first issue with the ADD_ADDR option is that since it is
   transmitted as a TCP option, it is not delivered reliably
   [Cellnet12].  When a host announces an IPv4 address, it can insert
   the ADD_ADDR option inside a segment that carries data that would
   thus be delivered reliably like user data.  However, if the ADD_ADDR
   option contains an IPv6 address, it might be too large to fit inside
   a segment that already contains a DSS option and possibly other
   options such as the [RFC1323] timestamps.  Given its length, the
   ADD_ADDR option cannot be placed in the same segment as a DSS option.
   In these two cases, the ADD_ADDR option will be often transmitted
   inside a duplicate ACK that is not delivered reliably.  [Cellnet12]
   proposes a method to improve the reliability of the transmission of
   the ADD_ADDR option, but to our knowledge this method has never been
   implemented.  To cope with packet losses, we propose to rely on the
   "E" (Echo) flag in the ADD_ADDR option (Figure 3).












Duchene & Bonaventure    Expires January 9, 2017                [Page 4]


Internet-Draft                 MPTCP ADDR                      July 2016


                        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    |Subtype|E|(rsv)|  Address ID   |
   +---------------+---------------+-------+-------+---------------+


   Figure 3: The part of the proposed Multipath TCP new ADD_ADDR option
                         format with the Echo flag

   The "E" flag is the "Echo" flag.  When set to 0, it indicates that
   the host sending this option is advertising a new address to the
   receiving host.  When set to 1, it indicates that the host sending
   this option acknowledges the reception of an ADD_ADDR option by
   echoing it.  Upon reception of an ADD_ADDR option without the "E"
   flag set, the receiving host MUST return the exact option that it
   received with the "E" flag set to 1 to indicate the reception of the
   ADD_ADDR option.  If an host advertising a new address does nt
   receive an echo, or receives an invalid echo of the option it MAY
   retransmit the ADD_ADDR.  To cope with the loss of the echo of the
   option, if an host that advertised a new address without receiving
   the echo receives an MP_JOIN on this address, it MUST consider this
   address as having been echoed, and MUST NOT retransmit this ADD_ADDR
   again.

2.2.  Backup

   The subflows that compose a Multipath TCP connection are not all
   equal.  [RFC6824] defines two types of subflows:

   o  the regular subflows

   o  the backup subflows

   The regular subflows can be used to transport any data.  The backup
   subflows are intended to be used only when all the regular subflows
   fail.  [RFC6824] defines them by using the following sentence: "Hosts
   can indicate at initial subflow setup whether they wish the subflow
   to be used as a regular or backup path - a backup path only being
   used if there are no regular paths available."

   In [RFC6824] a host can specify the type of a subflow during the
   three-way-handshake by using the "B" flag of the MP_JOIN option as
   shown in Figure 4 and Figure 5 or when the subflow is already
   established by sending an MP_PRIO option shown in Figure 6.






Duchene & Bonaventure    Expires January 9, 2017                [Page 5]


Internet-Draft                 MPTCP ADDR                      July 2016


                         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 = 12  |Subtype|     |B|   Address ID  |
   +---------------+---------------+-------+-----+-+---------------+
   |                   Receiver's Token (32 bits)                  |
   +---------------------------------------------------------------+
   |                Sender's Random Number (32 bits)               |
   +---------------------------------------------------------------+


       Figure 4: Join Connection (MP_JOIN) Option (for Initial SYN)

                         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 = 16  |Subtype|     |B|   Address ID  |
   +---------------+---------------+-------+-----+-+---------------+
   |                                                               |
   |                Sender's Truncated HMAC (64 bits)              |
   |                                                               |
   +---------------------------------------------------------------+
   |                Sender's Random Number (32 bits)               |
   +---------------------------------------------------------------+


    Figure 5: Join Connection (MP_JOIN) Option (for Responding SYN/ACK)

                        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    |Subtype|     |B| AddrID (opt) |
   +---------------+---------------+-------+-----+-+--------------+

            Figure 6: Change Subflow Priority (MP_PRIO) Option

   Both solutions rely on the principle that a subflow can be set in
   backup mode only when being already established or during the subflow
   setup.  On mobile devices, backup subflows consume radio ressources
   when they are established.  This could unnecessarily consume both
   energy on the mobile device [ATC14] and radio ressources in the
   network for subflows that do not carry any data.  Measurements on
   smartphones [PAM2016] indicate that many subflows do not carry any
   data but still consume resources for the SYN, RST and FIN packets.

   To allow hosts using Multipath TCP to save ressources, we propose to
   add the "B" "Backup" Flag in the ADD_ADDR option as shown in
   Figure 7.  This would allow an host to save ressources by being aware



Duchene & Bonaventure    Expires January 9, 2017                [Page 6]


Internet-Draft                 MPTCP ADDR                      July 2016


   of the remote backup addresses that could be used if all the non-
   backup subflows fail without having to establish a subflow, achieving
   a break-before-make scheme.

                        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
   +---------------+---------------+---------------+---------------+
   | Commu |prio |B|   Port (2 octets, optional)   |               |
   +---------------+---------------+---------------+               |


   Figure 7: The part of the proposed Multipath TCP new ADD_ADDR option
                        format with the Backup flag

2.3.  Priorities

   The backup mode defined in [RFC6824] only supports an "all-or-
   nothing" mode in the usage of the subflows, where an host might just
   prefer to use certain subflow over others.

   To allow an host to inform the receving host about its preference in
   terms of subflow usage, we propose to modify the ADD_ADDR option by
   adding 3 "priority" bits as shown in Figure 8.

                        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
   +---------------+---------------+---------------+---------------+
   | Commu |prio |B|   Port (2 octets, optional)   |               |
   +---------------+---------------+---------------+               |


   Figure 8: The part of the proposed Multipath TCP new ADD_ADDR option
                       format with the priority bits

   This host MAY use this priority to determine when to establish a
   subflow towards this address.  The priority field MUST be interpreted
   as an unsigned integer value with the highest numerical value being
   the most preferred one.

   To allow the priority of an already established subflow to be
   modified, we propose to modify the MP_PRIO option by adding the 3
   priority bits next to the "B" flag has shown in Figure 9.









Duchene & Bonaventure    Expires January 9, 2017                [Page 7]


Internet-Draft                 MPTCP ADDR                      July 2016


                        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    |Subtype|prio |B| AddrID (opt) |
   +---------------+---------------+-------+-----+-+--------------+

    Figure 9: Change Subflow Priority (MP_PRIO) Option with 3 priority
                                bits added

   To allow the hosts to advertise a per-subflow priority during the
   three-way-handshake we modify the MP_JOIN option by adding the 3
   priority bits as shown in Figure 10 and Figure 11,

                         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 = 12  |Subtype| prio|B|   Address ID  |
   +---------------+---------------+-------+-----+-+---------------+
   |                   Receiver's Token (32 bits)                  |
   +---------------------------------------------------------------+
   |                Sender's Random Number (32 bits)               |
   +---------------------------------------------------------------+


    Figure 10: Join Connection (MP_JOIN) Option (for Initial SYN) with
                            the 3 priority bits

                         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 = 16  |Subtype| prio|B|   Address ID  |
   +---------------+---------------+-------+-----+-+---------------+
   |                                                               |
   |                Sender's Truncated HMAC (64 bits)              |
   |                                                               |
   +---------------------------------------------------------------+
   |                Sender's Random Number (32 bits)               |
   +---------------------------------------------------------------+


   Figure 11: Join Connection (MP_JOIN) Option (for Responding SYN/ACK)
                         with the 3 priority bits

   The priority bits included in the MP_JOIN specify indicate the
   priority associated to this subflow.  A host MAY use this information
   when scheduling packets over this particular subflow.





Duchene & Bonaventure    Expires January 9, 2017                [Page 8]


Internet-Draft                 MPTCP ADDR                      July 2016


2.4.  Path diversity

                          +--- IPv4 1 ---+
                          |              |
                          +--- IPv6 1 ---+--- Interface 1 ---+
                          |              |                   |
   client --- Internet ---+--- IPv6 2 ---+                   |
                          |                                  +--- Server
                          |                                  |
                          |                                  |
                          +--- IPv4 1 ---+--- Interface 2 ---+

   Figure 12: A dual stack server with multiple IP addresses attached to
                            the same interface.

   As shown in Figure 12 a host might have several IP addresses assigned
   to a single interface.  Some clients would like to be able to create
   subflows over disjoint paths to maximise the diversity of the
   subflows.  With the current ADD_ADDR option, the host receiving
   several ADD_ADDR has no way of knowing the diversity between these
   path.  In the case of Figure 12 it could end up establishing 4
   subflows where 2 could be sufficient to maximise diversity.

   To allow a host to inform the receiving host about the diversity of
   several addresses we propose to modify the ADD_ADDR to include 4 bits
   describing a "Community" associated to this address.  The community
   values are an opaque field and it is expected that two addresses
   having the same community share some resources.

                        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
   +---------------+---------------+---------------+---------------+
   | Commu |B|prio |   Port (2 octets, optional)   |               |
   +---------------+---------------+---------------+               |


   Figure 13: The part of the proposed Multipath TCP new ADD_ADDR option
                      format with the Community bits

   With the community bits, a dual-stack host could elect to regroup all
   the addresses attached to a single interface under the same
   community, allowing the receiving host to decide on which advertised
   addresses it wants to establish new subflows.








Duchene & Bonaventure    Expires January 9, 2017                [Page 9]


Internet-Draft                 MPTCP ADDR                      July 2016


2.5.  Load balancing

   Many large web sites are served by servers that are behind a load
   balancer.  The load balancer receives the connection establishment
   attempts and forwards them to the actual servers that serve the
   requests.  One issue for the end-to-end deployment of Multipath TCP
   is it ability to be used on load-balancers.  Different types of load
   balancers are possible.  We consider a simple but important load
   balancer than does not maintain any per-flow state.  This load
   balancer is illustrated in illustrated in Figure 14.  A stateless
   load balancer can be implemented by hashing the five tuple (IP
   addresses and port numbers) of each incoming packet and forward them
   to one of the servers based on the hash value computed.  With TCP,
   this load balancer ensures that all the packets that belong to one
   TCP connection are sent to the same server.

      +--+---- S1
   ---|LB|---- S2
      +--+---- S3


                    Figure 14: Stateless load balancer

   With Multipath TCP, this approach cannot be used anymore when
   subflows are created by the clients.  Such subflows can use any five
   tuple and thus packets belonging to them will be forwarded over any
   server, not necessarily the one that was selected by the hashing
   function for the initial subflow.

   To allow Multipath TCP to work for hosts being hosted behind
   unmodified layer 4 load balancers, we propose to use the unused "B"
   flag in the MP_CAPABLE option sent (shown in Figure 15 in the
   SYN+ACK.  This flag would allow a host behind a layer 4 load balancer
   to inform the other host that this address MUST NOT be used to create
   additional subflows.

   A host receiving an MP_CAPABLE with the "B" set to 1 MUST NOT try to
   establish a subflow to the address used in the MP_CAPABLE.  This bit
   can also be used in the MP_CAPABLE option sent in the SYN by a client
   that resides behind a NAT or firewall or does not accept server-
   initiated subflows.










Duchene & Bonaventure    Expires January 9, 2017               [Page 10]


Internet-Draft                 MPTCP ADDR                      July 2016


                        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     |Subtype|Version|A|B|C|D|E|F|G|H|
   +---------------+---------------+-------+-------+---------------+
   |                   Option Sender's Key (64 bits)               |
   |                      (if option Length > 4)                   |
   |                                                               |
   +---------------------------------------------------------------+
   |                  Option Receiver's Key (64 bits)              |
   |                      (if option Length > 12)                  |
   |                                                               |
   +-------------------------------+-------------------------------+
   |  Data-Level Length (16 bits)  |  Checksum (16 bits, optional) |
   +-------------------------------+-------------------------------+


             Figure 15: Multipath Capable (MP_CAPABLE) Option

   This bit can be used by the servers behind a stateless load
   balancers.  Each of these servers has a different IP address than the
   address of the load balancer.  The servers set the "B" flag in the
   MP_CAPABLE option that they return and advertise their own address by
   using the ADD_ADDR option.  Upon reception of this option, the
   clients can create the additional subflows towards these addresses.
   Compared with current stateless load balancers, an advantage of this
   approach is that the packets belonging to the additional subflows do
   not need to pass through the load balancer.

3.  IANA considerations

   This document proposes some modifications to the Multipath TCP
   options defined in [RFC6824].  These modifications do not require any
   specific action from IANA.

4.  Security considerations

   The security considerations defined for Multipath TCP in [RFC6182]
   and [RFC7430] are applicable.

   The "E" flag, community and priority values in the ADD_ADDR option do
   not change the security considerations for the handling of this
   option.  Since the ADD_ADDR option is protected by an HMAC, an off-
   path attacker cannot inject such an option in an existing Multipath
   TCP connection.






Duchene & Bonaventure    Expires January 9, 2017               [Page 11]


Internet-Draft                 MPTCP ADDR                      July 2016


   The "priority" field of the MP_PRIO option is not protected by a
   HMAC.  It could be useful to consider the utilisation of an HMAC to
   protect this option like the ADD_ADDR option.

   The "B" flag of the MP_CAPABLE option does not change the security
   considerations of this option.  If an attacker that resides on a path
   sets this bit, it could prevent the establishment of subflows.
   However, Multipath TCP does not protect against an attacker that
   resides on the path of the initial subflow and can modify the SYN/
   SYN+ACK packets.

5.  Conclusion

   In this document, we have discussed several issues with the
   advertisement of addresses with the address advertisement in
   Multipath TCP.  We have proposed several modifications to the
   protocol to address these issues.

6.  References

6.1.  Normative References

   [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,
              <http://www.rfc-editor.org/info/rfc6824>.

6.2.  Informative References

   [ATC14]    Yeon-sup Lim, ., Yung-Chih Chen, ., Nahum, Erich., Don
              Towsley, ., and . Richard Gibbens, "How green is multipath
              TCP for mobile devices?", AllThingsCellular14 , 2014.

   [Cellnet12]
              Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O.
              Bonaventure, "Exploring Mobile/WiFi Handover with
              Multipath TCP", ACM SIGCOMM workshop on Cellular Networks
              (Cellnet12) , 2012,
              <http://inl.info.ucl.ac.be/publications/
              exploring-mobilewifi-handover-multipath-tcp>.

   [I-D.ietf-mptcp-rfc6824bis]
              Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
              Paasch, "TCP Extensions for Multipath Operation with
              Multiple Addresses", draft-ietf-mptcp-rfc6824bis-06 (work
              in progress), July 2016.





Duchene & Bonaventure    Expires January 9, 2017               [Page 12]


Internet-Draft                 MPTCP ADDR                      July 2016


   [PAM2016]  Quentin De Coninck, ., Matthieu Baerts, ., Benjamin
              Hesmans, ., and O. Bonaventure, "A First Analysis of
              Multipath TCP on Smartphones", 17th International Passive
              and Active Measurements Conference , April 2016,
              <http://inl.info.ucl.ac.be/publications/
              first-analysis-multipath-tcp-smartphones>.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC1323]  Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
              1992, <http://www.rfc-editor.org/info/rfc1323>.

   [RFC6182]  Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
              Iyengar, "Architectural Guidelines for Multipath TCP
              Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
              <http://www.rfc-editor.org/info/rfc6182>.

   [RFC7430]  Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C.
              Raiciu, "Analysis of Residual Threats and Possible Fixes
              for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/
              RFC7430, July 2015,
              <http://www.rfc-editor.org/info/rfc7430>.

Authors' Addresses

   Fabien Duchene
   UCLouvain

   Email: fabien.duchene@uclouvain.be


   Olivier Bonaventure
   UCLouvain

   Email: Olivier.Bonaventure@uclouvain.be













Duchene & Bonaventure    Expires January 9, 2017               [Page 13]


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