idnits 2.17.1 draft-boucadair-mptcp-extensions-00.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 (June 16, 2015) is 3208 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- No information found for draft-bonaventure-mptcp-exp-option - is the name correct? ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 France Telecom 5 Expires: December 18, 2015 June 16, 2015 7 Negotiating the Maximum Number of MPTCP Subflows 8 draft-boucadair-mptcp-extensions-00 10 Abstract 12 This document specifies an experimental MPTCP option that is meant to 13 negotiate the maximum number of subflows that can be established and 14 maintained for a given MPTCP connection. The purpose is to minimize 15 any possible performance degradation that can be induced by a 16 possibly large number of establishment requests for additional 17 subflows if the remote endpoint is not appropriateley dimensioned to 18 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 December 18, 2015. 43 Copyright Notice 45 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . 3 63 3. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 69 7.2. Informative References . . . . . . . . . . . . . . . . . 4 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 This document specifies a MPTCP option that is meant to indicate to a 75 remote peer the maximum number of subflows that can be established 76 within a single MPTCP connection. If the remote peer honors the 77 indication provided in this option, any performance degradation 78 induced by a possibly abusive setup of additional subflows that 79 exceed the said maximum becomes unlikely. 81 This document adheres to [I-D.bonaventure-mptcp-exp-option]. 83 This option targets mainly MPTCP deployments within a single 84 administrative domain such as those MPTCP designs meant to achieve 85 load-balancing, for example. The use of this option contributes to 86 the harmonization of node configuration within an administrative 87 domain, so that an optimal number of subflows is maintained by 88 involved nodes independently of their actual performance 89 capabilities. This option can be used for other deployment 90 scenarios. It is out of scope of this document to identify an 91 exhaustive list of such scenarios. 93 1.1. Experiment Goals 95 Experiments based upon the MPTCP option described in this document 96 are meant to help operators refine their MPTCP design and operational 97 procedures, by tweaking some MPTCP parameters such as the number of 98 subflows to be associated with a given MPTCP connection. 99 Experimenting with this MPTCP option should also help assess whether 100 this option can be used to propagate MPTCP-related optimization 101 parameters (derived from the number of concurrent subflows associated 102 to each MPTCP connection) that can be configured in a node that is 103 responsible for aggregating MPTCP connections established with 104 upstream nodes. 106 2. Maximum Subflows MPTCP Option 108 This option follows the shared experimental format defined in 109 [I-D.bonaventure-mptcp-exp-option] (see Figure 1). 111 1 2 3 112 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 113 +---------------+---------------+-------+-----------------------+ 114 | Kind | Length |Subtype| Flags | Experiment | 115 +---------------+---------------+-------+-------+---------------+ 116 | Id. (16 bits) | Maximum Sub-Flows | 117 +---------------+-----------------------------------------------+ 119 Figure 1: Option Format 121 The meaning of "Kind", "Length", "Subtype", and "Flags" (especially 122 'S' and 'U' flags) are exactly the same as defined in 123 [I-D.bonaventure-mptcp-exp-option]. 125 Experiment ID (to be assigned, see Section 5). 127 The "Maximum Sub-Flows" field indicates the number of maximum 128 concurrent subflows that can be maintained by a given MPTCP endpoint 129 for each MPTCP connection established by or with this endpoint. The 130 value of this field MUST be strictly greater than zero. 132 3. Behavior 134 The option defined in Section 2 is used by a TCP endpoint to indicate 135 to its corresponding peer the maximum number of subflows that it can 136 maintain per MPTCP connection. 138 If two peers (T1 and T2) indicate the maximum number of concurrent 139 subflows per connection they can maintain, then they MUST NOT 140 maintain more than "MIN(MAX_SUBFLOW(T1), MAX_SUBFLOW(T2))" concurrent 141 subflows. 143 The absence of this option in an MPTCP control message issued by a 144 MPTCP endpoint is an indication that this endpoint can instantiate 145 any number of subflows per MPTCP connection. 147 If no maximum number of subflows is configured locally to an MPTCP 148 endpoint, it may rely on the results of procedures such as 149 [I-D.boucadair-mptcp-connectivity-checks] as a hint to determine the 150 value to include in the "Maximum Sub-Flows" MPTCP option. 152 4. Security Considerations 154 MPTCP-related security considerations are documented in [RFC6824] and 155 [I-D.ietf-mptcp-attacks]. 157 5. IANA Considerations 159 This document requests IANA to assign an experiment ID as per 160 [I-D.bonaventure-mptcp-exp-option]. 162 6. Acknowledgements 164 TBC 166 7. References 168 7.1. Normative References 170 [I-D.bonaventure-mptcp-exp-option] 171 Bonaventure , O., Hesmans, B., and M. Boucadair, 172 "Experimental Multipath TCP option", 1992. 174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 175 Requirement Levels", BCP 14, RFC 2119, March 1997. 177 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 178 "TCP Extensions for Multipath Operation with Multiple 179 Addresses", RFC 6824, January 2013. 181 7.2. Informative References 183 [I-D.boucadair-mptcp-connectivity-checks] 184 Boucadair, M. and C. Jacquenet, "MPTCP Connectivity 185 Checks", draft-boucadair-mptcp-connectivity-checks-00 186 (work in progress), March 2015. 188 [I-D.ietf-mptcp-attacks] 189 Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 190 Raiciu, "Analysis of MPTCP residual threats and possible 191 fixes", draft-ietf-mptcp-attacks-04 (work in progress), 192 March 2015. 194 Authors' Addresses 196 Mohamed Boucadair 197 France Telecom 198 Rennes 35000 199 France 201 Email: mohamed.boucadair@orange.com 203 Christian Jacquenet 204 France Telecom 205 Rennes 35000 206 France 208 Email: christian.jacquenet@orange.com