idnits 2.17.1 draft-mrc-banana-considerations-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2842 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 118, but not defined == Unused Reference: 'RFC6126' is defined on line 345, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6126 (Obsoleted by RFC 8966) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet Working Group M. Cullen 3 Internet-Draft Painless Security 4 Intended status: Informational M. Zhang 5 Expires: January 9, 2017 Huawei Technologies 6 July 8, 2016 8 Considerations for Bandwidth Aggregation 9 draft-mrc-banana-considerations-01 11 Abstract 13 This document lists a number of architectural and technical topics 14 that should be considered in the design and implementation of 15 Bandwidth Agregation mechanisms. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 9, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. What is Bandwidth Aggregation? . . . . . . . . . . . . . . . 3 53 3. Taxonomy of Solutions . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Tunnel-Based Solutions . . . . . . . . . . . . . . . . . 3 55 3.2. Per-Packet vs. Per-Flow Multiplexing . . . . . . . . . . 3 56 4. Considerations for All Solutions . . . . . . . . . . . . . . 4 57 4.1. Link Characteristics and Performance . . . . . . . . . . 4 58 4.2. Bypass Traffic . . . . . . . . . . . . . . . . . . . . . 4 59 4.3. Capped or Tariffed Interfaces . . . . . . . . . . . . . . 4 60 4.4. Learning from History (Multilink PPP) . . . . . . . . . . 4 61 5. Considerations for Tunnel-Based Solutions . . . . . . . . . . 5 62 5.1. Tunnel Overhead . . . . . . . . . . . . . . . . . . . . . 5 63 5.2. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.2.1. Fragmentation Issues . . . . . . . . . . . . . . . . 5 65 5.2.2. Issues with MTU Changes . . . . . . . . . . . . . . . 5 66 6. Considerations for Per-Packet Solutions . . . . . . . . . . . 5 67 6.1. Packet Ordering . . . . . . . . . . . . . . . . . . . . . 5 68 6.2. Transport Layer Algorithms . . . . . . . . . . . . . . . 5 69 7. Considerations for Per-Flow Solutions . . . . . . . . . . . . 6 70 7.1. Granularity Issues . . . . . . . . . . . . . . . . . . . 6 71 7.2. Aggregated Flows . . . . . . . . . . . . . . . . . . . . 6 72 7.3. Encrypted Traffic . . . . . . . . . . . . . . . . . . . . 7 73 8. Practical Considerations . . . . . . . . . . . . . . . . . . 7 74 8.1. Use Available Information . . . . . . . . . . . . . . . . 7 75 8.2. Theory is No Substitute for Experience . . . . . . . . . 7 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 9.1. Binding Tunnel Endpoints . . . . . . . . . . . . . . . . 7 78 10. Appendix A: List of Solutions . . . . . . . . . . . . . . . . 7 79 10.1. Multilink PPP . . . . . . . . . . . . . . . . . . . . . 8 80 10.2. GRE Tunnel Binding . . . . . . . . . . . . . . . . . . . 8 81 10.3. LISP-Based Solution . . . . . . . . . . . . . . . . . . 8 82 10.4. MIP-Based Solution . . . . . . . . . . . . . . . . . . . 8 83 10.5. MP-TCP-Based Solution . . . . . . . . . . . . . . . . . 8 84 11. Informative References . . . . . . . . . . . . . . . . . . . 8 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 87 1. Introduction 89 There are currently several bandwidth aggregation solutions being 90 discussed within the IETF or other parts of the Internet industry. 91 This document discusses a number of technical and architectural facts 92 that should be considered in the design and implementation of those 93 solutions. This document is intended to provide useful information 94 to the community, not to state requirements or advocate for a 95 particular solution. 97 There is one simple thought underlying many of the considerations in 98 this document: the goals of bandwidth aggregation are to increase the 99 effective bandwidth available to customers and improve the 100 reliability of customers' Internet access by using all of the 101 available links, not just one of them. Intuitively, two links should 102 have more bandwidth and reliability than one link, but experience 103 shows that it is actually quite hard to design a bandwidth 104 aggregation solution that will achieve the desired goals in all 105 cases, and quite easy to design a solution that will reduce the 106 effective bandwidth or decrease the reliability of Internet access in 107 an unacceptably high number of cases. Many of the considerations in 108 this document are intended to point out why that happens, so that 109 solutions and implementations can avoid known pitfalls in this area. 111 [Note: This document is a work in progress. Feedback on the existing 112 content is welcome, as well as feeback on other considerations that 113 should be included. Please send any feedback to the Bandwidth 114 Aggregation mailing list: banana@ietf.org] 116 2. What is Bandwidth Aggregation? 118 [TBD] 120 3. Taxonomy of Solutions 122 This section attempts to catergorize bandwidth aggregation solutions 123 along several axes, providing a taxonomy tbat we can use to describe 124 and reason about individual solutions. [Note: This section is 125 largely TBD.] 127 3.1. Tunnel-Based Solutions 129 Many of the Bandwidth Aggregations currently under discussion are 130 tunnel-based solutions. They tunnel traffic over the links that are 131 being aggregated, and recombine the traffic on the remote end. 133 [Insert ASCII image of tunnel-based approach.] 135 There is at least one proposal for Bandwith Aggregation (the MP-TCP- 136 based approach) that does not use tunnels. The considerations for 137 tunnel-based solutions listed below may not apply to non-tunnel-based 138 solutions. 140 3.2. Per-Packet vs. Per-Flow Multiplexing 142 The solutions currently under discussion use several different 143 methods to determine which traffic will be sent over which interface. 145 These methods can be grouped into two categories: per-packet 146 multiplexing and per-flow multiplexing. 148 Per-packet multiplexing aggregates the bandwidth by sending the 149 desired proportion of packets over each interface. In these 150 solutions, packets from single flow (such as a TCP connection) may be 151 split across multiple interfaces and will need to be recombined at 152 the remote end. However, the ability to multiplex on a per-packet 153 basis makes it possible to most precisely apportion traffic across 154 the available bandwidth. 156 Per-flow multiplexing involves choosing a single interface for each 157 flow (i.e. TCP connection or application session) and sending all of 158 the packets for a single flow across that interface. In these 159 solutions, the flow do not need to be combined on the remote end. 160 However, the ability to balance traffic between multiple links may be 161 limited if there are only a small number of traffice flows active. 163 4. Considerations for All Solutions 165 This section desribes potential issues that should be considered in 166 the design and implementation of all bandwidth aggregation solutions. 168 4.1. Link Characteristics and Performance 170 4.2. Bypass Traffic 172 4.3. Capped or Tariffed Interfaces 174 In some cases, bandwith aggregation may be performed between 175 dedicated links and links that have traffic caps or tarifs associated 176 with additional use. In these cases, customer may want to use 177 bandwidth aggregation to increase the performance of some 178 applications, while other applications (e.g. firmware upgrades or 179 content downloads) may be limited to using the dedicated link. 180 Solutions that wish to support this capability will need to support 181 having a set of traffic that will be distributed using the bandwidth 182 aggregation algorithms, and a set of traffic that will not. 184 4.4. Learning from History (Multilink PPP) 186 The IETF has a venerable, standard, implemented solution to this sort 187 of problem: Multilink PPP. Unfortunately, it is commonly said that 188 experience with Multilink PPP did not find that it increased the 189 effective bandwidth when it was used to share two indentical ISDN 190 lines, compared to the bandwidth that was achieved from using only 191 one line... 193 [Note: We should attempt to determine if this is true and, if so, 194 find any research papers or other documentation that might help us 195 understand why this was true, so that we might learn from history.] 197 5. Considerations for Tunnel-Based Solutions 199 5.1. Tunnel Overhead 201 Tunneling involves more overhead than sending non-tunnelled traffic 202 for two reasons: the extra IP and tunnel headers that must be 203 included in each packet, and any tunnel management traffic that must 204 be exchanged. This means that, in order to achieve increased 205 effective bandwidth by aggregating traffic across more than one link, 206 the raw bandwidth across multiple links must be higher than the 207 bandwidth on a single link by a large enough margin to compensate for 208 the tunnel overhead, so that increased effective bandwidth will 209 result. 211 5.2. MTU Issues 213 There are a number of MTU Issues associated with all tunneling 214 mechanisms, and there is a different set of MTU issues associated 215 with any mechanism that changes the MTU of packets within a given 216 flow. 218 [Note: This section is TBD.] 220 5.2.1. Fragmentation Issues 222 5.2.2. Issues with MTU Changes 224 6. Considerations for Per-Packet Solutions 226 6.1. Packet Ordering 228 6.2. Transport Layer Algorithms 230 There are transport layer congestion control algorithms implemented 231 in every TCP/IP stack. It is the purpose of these algorithms to ramp 232 up the speed of a TCP connection slowly, and to back off at the first 233 sign of congestion (i.e. packet loss). There are also algorithms 234 which are designed to detect packet loss as quickly as possible by 235 analyzing the protocol round-trip times, and deciding that a packet 236 has been lost whenever there is a longer delay than expected before 237 an acknowledgement is received. Per-packet solutions run the risk of 238 interacting pathologically with these algorithms. 240 For example, if traffic from a single flow is being demultiplexed 241 across two links with significantly different round-trip times (i.e. 242 differnt latencies), the TCP retransmission algorithms may be 243 triggered for packets that traverse the higher latency link. This 244 may cause the TCP congestion control algorithms to inaccurately 245 detect congestion (even when neither link is congested) and slow down 246 the speed of the TCP connetion. In these cases, the throughput of 247 each TCP connection may be reduced, thus reducing the performance of 248 a customer's applications to the point where their applicaitons would 249 have run faster over a single link. 251 This problem can potentially be avoided by avoiding aggregation of 252 links with significantly different latencies. However, it may be 253 desirable to perform bandwidth aggregation across those links in some 254 cases. 256 7. Considerations for Per-Flow Solutions 258 This section describes some potential issues that should be 259 considered in the design of per-flow bandwidth aggregation solutions. 261 7.1. Granularity Issues 263 Per-Flow demultiplexing is in widespread use for traffic engineering 264 and load balancing in carrier and corporate networks. Within those 265 networks, there are a very large number of flows, so being able to 266 direct traffic on a per-flow basis will generally be sufficient to 267 achieve acceptable load-balancing or link aggregation. 269 However, the number of flows generated by a single home or small 270 office might not provide sufficient granularity to achieve the desire 271 level of bandwidth aggregation. Also some flows, such as streaming 272 video flows, might use far more bandwidth than other, such as 273 downloading a single image on a web page. It is not always possible 274 to predict which flows will be high-bandwidth flows, and which will 275 require less bandwidth. 277 7.2. Aggregated Flows 279 Some Internet flows are aggregated into single, larger flows at the 280 end-nodes. This would include VPN traffic that is tunnelled to a 281 corporate intranet, or other tunnelled traffic such as Teredo traffic 282 for IPv6. Use of these mechanisms can prevent proper classification 283 of traffic into separate flows, thus exacerbating the granularity 284 issues described above. 286 7.3. Encrypted Traffic 288 In some cases such as secure VPN traffic, the contents of packets may 289 be encrypted in a way that does not allow a middlebox to see the 290 transport-layer flow inforamtion (such as TCP or UDP ports). In 291 these cases, it might not be possible to properly separate multiple 292 flows between a single set of endpoints. This can exacerbate the 293 granularity issues described above. 295 8. Practical Considerations 297 8.1. Use Available Information 299 In many of the environments in which these mechanisms will be 300 deployed, there is already considerable informaiton available about 301 link quality, lost packets, traffic loads and effective bandwidth. 302 It is possible to use that information to actively tune a bandwidth 303 aggregation solution to achieve optimal effective bandwidth. This 304 information can also be used to detect situations in which the link 305 quality of a secondary link is not sufficient to provide enough 306 additional bandwidth to compensate for the bandwidth aggregation 307 overhead. 309 8.2. Theory is No Substitute for Experience 311 Because of the complexity of the algorithms implemented at multiple 312 layers of the TCP/IP Stack, many things that would appear to work in 313 theory or in limited simulation do not have the expected results when 314 deployed in a real-world environment. Therefore, it would be highly 315 desirable to have real-world experience running a bandwidth 316 aggregation mechanism in an operational network before standardizing 317 it within the IETF. 319 9. Security Considerations 321 9.1. Binding Tunnel Endpoints 323 10. Appendix A: List of Solutions 325 This is a (possibly incomplete) list of current or proposed solutions 326 for Bandwidth Aggregation. The descriptions in this section (when 327 present) were provided by the proponents of each solution. This list 328 is provided only as a source of information about possible solutions, 329 not as a recommendation for or against any of these solutions. 331 [Note: Insert information from Google Doc in this section.] 333 10.1. Multilink PPP 335 10.2. GRE Tunnel Binding 337 10.3. LISP-Based Solution 339 10.4. MIP-Based Solution 341 10.5. MP-TCP-Based Solution 343 11. Informative References 345 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 346 DOI 10.17487/RFC6126, April 2011, 347 . 349 Authors' Addresses 351 Margaret Cullen 352 Painless Security 353 14 Summer Street, Suite 202 354 Malden, MA 02148 355 USA 357 Phone: +1 781 405-7464 358 Email: margaret@painless-security.com 359 URI: http://www.painless-security.com 361 Mingui Zhang 362 Huawei Technologies 364 Email: zhangmingui@huawei.com