idnits 2.17.1 draft-zhang-banana-tcp-in-bonding-tunnels-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 21, 2016) is 2956 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BANANA M. Zhang 3 Internet Draft Huawei 4 Intended Category: Informational N. Leymann 5 C. Heidemann 6 Deutsche Telekom AG 7 M. Cullen 8 Painless Security 9 Expires: September 22, 2016 March 21, 2016 11 Flow Control for Bonding Tunnels 12 draft-zhang-banana-tcp-in-bonding-tunnels-00.txt 14 Abstract 16 Tunnel bonding enables Bandwidth Aggregation across multiple Internet 17 access links. From the practice of deployment, flow control is a 18 desirable feature of the bonding tunnel. This document explores the 19 way to equip bonding tunnel with flow control mechanism. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 61 3. A Network Based Sliding Window . . . . . . . . . . . . . . . . 3 62 4. Bonding De-Activation . . . . . . . . . . . . . . . . . . . . . 4 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 68 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 Bandwidth aggregation capabilities across multiple Internet access 73 links can significantly improve end users' Quality of Experience. 74 Lots of service providers who possess multiple access networks are 75 about to deploy or have already deployed the bandwidth aggregation 76 capabilities. There are various enabling techniques arising to 77 address bandwidth aggregation issues [Problem]. Among them, tunneling 78 techniques are promising since the network-based requirement can be 79 fulfilled easily. 81 To achieve bandwidth aggregation, two tunnels are to be bonded 82 together to form a single logical tunnel in between the access and 83 aggregation equipments. When the bandwidth of the primary tunnel 84 fills, the secondary tunnel can be used to accommodate the excessive 85 load, while end users are supposed not to be aware of the shifting. 87 Flow control is a desirable feature for bandwidth aggregation. In 88 this document, TCP-like sliding window mechanism is integrated into 89 the tunnel to handle the packet delay, loss and network congestion. 90 However, considering the overhead that may be introduced into the 91 tunnel, the transportation utilities used here will not cover a full 92 set of TCP functions. 94 In the practical deployment, the quality of the two bonded tunnels 95 may become un-comparable. The bonding mode will be deactivated and 96 user's traffic will be carried using the primary tunnel only. From 97 calculating of the Adaptive Time-Out in the flow control, operators 98 can judge whether the bonding mode should be deactivated. 100 2. Acronyms and Terminology 102 Hybrid Access: The bonding of multiple access connections based on 103 heterogeneous technologies (e.g., DSL and LTE) that are provided by 104 the same carrier. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 3. A Network Based Sliding Window 112 This document equips bonded tunnels with the well-known sliding 113 window mechanism, which used to be a well-know TCP utility, to handle 114 packet loss, packet delay and congestions introduced by the bonding 115 tunnel. Compared to the sliding windows that are implemented on end- 116 systems, this document specifies a network based sliding window 117 mechanism. 119 In order to realize the sliding window mechanism, sequence number and 120 acknowledgement number are required. Note that the sequence number 121 specified in this document is used to number packets sent on each 122 individual tunnel. It is different from the sequence number that is 123 used for packet reordering for the entire bonding tunnel [GREbond]. 124 However, the two sequence numbers maybe concatenated to use the 4- 125 octet Sequence Number field of the GRE header [GREbond]. The sequence 126 number for the entire bonding tunnel uses the higher order two octets 127 while the sequence number of the individual tunnel uses the lower 128 order two octets. 130 Based on this sequence number and acknowledgement number, 131 retransmission could be realized. However, considering the heavy 132 overhead that might be caused, HCPE and HAG will not perform 133 retransmission. Retransmission might be realized in accompanied TCP 134 proxies or accelerators, but it is out the scope of this document. 135 The individual tunnels will merely adopt sliding window mechanism to 136 moderate the rate at which the data is being transmitted. To support 137 such a mechanism, the HCPE and HAG devices are required to implement 138 a sending window. 140 Sequence numbers and acknowledgement numbers are maintained per 141 individual tunnels. Sequence numbers have to be piggybacked on data 142 packets while acknowledgement numbers can be sent separately from 143 data packets. Each bonding tunnel is treated as a constant long-live 144 session. Sliding window protocol of [RFC2637] will be used as the 145 basis. The following changes to RFC 2637 are required. 147 (Section 4.2.4. Window Overflow) When a receiver's window overflows 148 with too many incoming packets, the receiver immediately starts to 149 digest the packets in the window and put them into the reordering 150 buffer, even if there are missing packets. This process continues 151 until excess packets are accommodated. When the secondary 152 transmission window fills, no more traffic should be distributed to 153 the secondary tunnel. Packets will enter the primary transmission 154 window. 156 (Section 4.2.5. Multi-packet Acknowledgment) Each packet is 157 acknowledged as it enters the reordering buffer of the bonding 158 tunnel. When the receiving window overflows, packets are digested 159 even if there are missing packets with lower sequence number. At that 160 point, those digested packets will be acknowledged as well. 162 (Section 4.3. Out-of-sequence Packets) Out of sequence packets are 163 not dropped. Instead, they will be digested and enter the reordering 164 buffer of the bonding tunnel. For these out-of-sequence packets, no 165 acknowledgement will be sent. 167 (Section 4.4.1. Calculating Adaptive Acknowledgment Time-Out) When a 168 time-out occurs for the secondary tunnel, the sending device will not 169 stop distributing packets onto the secondary tunnel as long as a good 170 throughput is promised (i.e., the transmission window does not fill), 171 unless the difference of the ATOs of the two tunnels exceeds the 172 configured MaxDiffTimeOut. In the case that the difference of ATOs 173 exceeds MaxDiffTimeOut or the secondary transmission window fills, no 174 packets will be distributed to the secondary tunnel. Packets remained 175 in the secondary transmission window will be moved to the primary 176 transmission window. 178 4. Bonding De-Activation 180 In the practical deployment, the secondary connection might suffer 181 from large latency, jitter and high packet loss rate. In the bonding 182 tunnel, packets are distributed onto both primary and secondary 183 tunnels at one end and then recombined again in a buffer at the 184 receiver. If the secondary GRE tunnel suffers, the entire bonding 185 tunnel will suffer as well due to the recombination function. For 186 example, assume packet 1 is distributed onto the secondary GRE tunnel 187 while packet 2 is distributed onto the primary GRE tunnel. If packet 188 1 is delayed by 100 ms, even packet 2 arrives at the recombination 189 butter at the first ms, it has to remain in the buffer awaiting for 190 99 ms for packet 1. 192 Deployment experiences show that the TCP throughput of the bonding 193 tunnel might be greatly reduced due to the downgrade or disruption of 194 the secondary tunnel. Hence, monitoring the performance of the 195 secondary tunnel is required. Based on the monitoring, when the 196 performance of the two links are comparable operators will remain the 197 bonding mode open. Otherwise, when the monitored performance 198 parameters do not meet their predefined requirements, the bonding 199 mode will be de-activated so that the HCPE and HAG only use the 200 primary connection. As specified in Section 3, the calculation of the 201 Adaptive Acknowledgment Time-Out provides such kind of monitoring. 203 5. Security Considerations 205 Unless the payload data and control messages carried in the tunnels 206 are cryptographically protected, they can be captured and read or 207 modified. Attackers may make up bogus sequence numbers and 208 acknowledge numbers to cause replay or deny of service attacks. 210 6. IANA Considerations 212 No new registration is required to be allocated from IANA. RFC 213 editor, please remove this section before its publication. 215 7. References 217 7.1. Normative References 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, DOI 221 10.17487/RFC2119, March 1997, . 224 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 225 and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", 226 RFC 2637, DOI 10.17487/RFC2637, July 1999, . 229 [GREbond] Leymann, N., Heidemann, C. , et al, "GRE Tunnel Bonding", 230 draft-zhang-gre-tunnel-bonding, Work in Progress. 232 7.2. Informative References 234 [Problem] Cullen, M., et al, "Problem Statement: Bandwidth 235 Aggregation for Internet Access", Work in Progress, draft- 236 zhang-banana-problem-statement, Work in Progress. 238 Author's Addresses 240 Mingui Zhang 241 Huawei Technologies 242 No. 156 Beiqing Rd., Haidian District 243 Beijing 100095 244 China 246 Email: zhangmingui@huawei.com 248 Nicolai Leymann 249 Deutsche Telekom AG 250 Winterfeldtstrasse 21-27 251 Berlin 10781 252 Germany 254 Phone: +49-170-2275345 255 EMail: n.leymann@telekom.de 257 Cornelius Heidemann 258 Deutsche Telekom AG 259 Heinrich-Hertz-Strasse 3-7 260 Darmstadt 64295 261 Germany 263 Phone: +4961515812721 264 Email: heidemannc@telekom.de 266 Margaret Cullen 267 Painless Security 268 14 Summer St. Suite 202 269 Malden, MA 02148 270 United States 272 Email: margaret@painless-security.com