idnits 2.17.1 draft-boucadair-mptcp-max-subflow-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 24, 2016) is 2700 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-mptcp-rfc6824bis-07 ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental Orange 5 Expires: May 28, 2017 November 24, 2016 7 Negotiating the Maximum Number of Multipath TCP (MPTCP) Subflows 8 draft-boucadair-mptcp-max-subflow-03 10 Abstract 12 This document specifies an experimental Multipath TCP (MPTCP) option 13 that is meant to negotiate the maximum number of subflows that can be 14 established and maintained for a given MPTCP connection. The purpose 15 is to minimize any possible performance degradation that can be 16 induced by a possibly large number of establishment requests for 17 additional subflows if the remote endpoint is not appropriately 18 dimensioned to handle such requests. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 28, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Experiment Goals . . . . . . . . . . . . . . . . . . . . 3 62 2. Maximum Subflows MPTCP Option (MP_MAXSUBFLOW) . . . . . . . . 3 63 3. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 6.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 This document specifies a Multipath TCP (MPTCP) [RFC6824] option that 74 is meant to indicate to a remote peer the maximum number of subflows 75 that can be established within a single MPTCP connection. If the 76 remote peer honors the indication provided in this option, any 77 performance degradation induced by a possibly abusive setup of 78 additional subflows that exceed the said maximum becomes unlikely. 80 This option mainly targets MPTCP deployments within a single 81 administrative domain such as those MPTCP designs meant to achieve 82 load-balancing, for example. The use of this option contributes to 83 the harmonization of node configuration within an administrative 84 domain, so that an optimal number of subflows is maintained by 85 involved nodes independently of their actual performance 86 capabilities. This option can be used in other deployment scenarios. 87 It is out of scope of this document to identify what are such 88 scenarios. 90 Section 3.4 of [I-D.ietf-mptcp-experience] includes a discussion on 91 the MPTCP session manager issues. That document states that creating 92 subflows between multihomed clients and servers may sometimes lead to 93 operational issues. The present document targets to soften these 94 issues. 96 1.1. Experiment Goals 98 Experiments based upon the MPTCP option described in this document 99 are meant to help operators optimize their MPTCP design and 100 operational procedures, by tweaking some MPTCP parameters such as the 101 number of subflows to be associated with a given MPTCP connection. 102 Experimenting with this MPTCP option should also help assess whether 103 this option can be used to propagate MPTCP-related optimization 104 parameters (derived from the number of concurrent subflows associated 105 to each MPTCP connection) that can be configured in a node that is 106 responsible for aggregating MPTCP connections established with 107 upstream nodes. 109 2. Maximum Subflows MPTCP Option (MP_MAXSUBFLOW) 111 The MP_MAXSUBFLOW option (Figure 1) follows the shared experimental 112 format defined in [I-D.ietf-mptcp-rfc6824bis]. 114 1 2 3 115 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 116 +---------------+---------------+-------+-----------------------+ 117 | Kind | Length |Subtype| Flags | Experiment Id | 118 +---------------+---------------+-------+-------+---------------+ 119 | Maximum Subflows | 120 +---------------+-----------------------------------------------+ 122 Figure 1: Option Format 124 The meaning of "Kind", "Length", "Subtype", and "Flags" (especially 125 'S' and 'U' flags) are exactly the same as defined in Section 3.7 of 126 [I-D.ietf-mptcp-rfc6824bis]. 128 Experiment ID MUST be set to 0xAA (see Section 5). 130 The "Maximum Subflows" field indicates the maximum number of 131 concurrent subflows that can be maintained by a given MPTCP endpoint 132 for each MPTCP connection established by or with this endpoint. The 133 value of this field MUST be strictly greater than zero. 135 3. Behavior 137 The MP_MAXSUBFLOW option may be used by a TCP endpoint to indicate to 138 its corresponding peer the maximum number of subflows that it can 139 maintain per MPTCP connection. 141 How an MPTCP endpoint determines the maximum number of concurrent 142 subflows it supports (i.e., the value it indicates in an 143 MP_MAXSUBFLOW option) is implementation-specific. For example, an 144 implementation may support a configuration parameter and/or use a 145 default value. 147 If two peers (T1 and T2) indicate the maximum number of concurrent 148 subflows per connection they can maintain, then they MUST NOT 149 maintain more than "MIN(MAX_SUBFLOW(T1), MAX_SUBFLOW(T2))" concurrent 150 subflows. 152 The absence of the MP_MAXSUBFLOW option in an MPTCP control message 153 issued by a MPTCP endpoint is an indication that this endpoint can 154 instantiate any number of subflows per MPTCP connection. 156 4. Security Considerations 158 MPTCP-related security considerations are documented in [RFC6824] and 159 [RFC7430]. 161 Establishing a large number of subflows may exhaust the resources of 162 an MPTCP implementation (especially, MPTCP servers). MPTCP 163 implementations SHOULD rate-limit the number of concurrent subflows 164 per MPTCP connection. This policy is meant to prevent DoS attacks 165 that would result in creating additional subflows to exhaust the 166 remote peer resources (typically, an MPTCP server). 168 5. IANA Considerations 170 This document uses the experiment Id (0xAA). This Id is not 171 registered yet given that no registry is maintained by IANA for this 172 purpose. 174 6. References 176 6.1. Normative References 178 [I-D.ietf-mptcp-rfc6824bis] 179 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 180 Paasch, "TCP Extensions for Multipath Operation with 181 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-07 (work 182 in progress), October 2016. 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, 186 DOI 10.17487/RFC2119, March 1997, 187 . 189 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 190 "TCP Extensions for Multipath Operation with Multiple 191 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 192 . 194 6.2. Informative References 196 [I-D.ietf-mptcp-experience] 197 Bonaventure, O., Paasch, C., and G. Detal, "Use Cases and 198 Operational Experience with Multipath TCP", draft-ietf- 199 mptcp-experience-07 (work in progress), October 2016. 201 [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 202 Raiciu, "Analysis of Residual Threats and Possible Fixes 203 for Multipath TCP (MPTCP)", RFC 7430, 204 DOI 10.17487/RFC7430, July 2015, 205 . 207 Authors' Addresses 209 Mohamed Boucadair 210 Orange 211 Rennes 35000 212 France 214 Email: mohamed.boucadair@orange.com 216 Christian Jacquenet 217 Orange 218 Rennes 35000 219 France 221 Email: christian.jacquenet@orange.com