BANANA M. Zhang Internet Draft Huawei Intended Category: Informational N. Leymann C. Heidemann Deutsche Telekom AG M. Cullen Painless Security Expires: September 22, 2016 March 21, 2016 Flow Control for Bonding Tunnels draft-zhang-banana-tcp-in-bonding-tunnels-00.txt Abstract Tunnel bonding enables Bandwidth Aggregation across multiple Internet access links. From the practice of deployment, flow control is a desirable feature of the bonding tunnel. This document explores the way to equip bonding tunnel with flow control mechanism. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License 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 Mingui Zhang, et al Expires September 22, 2016 [Page 1] INTERNET-DRAFT TCP in Bonding Tunnels March 21, 2016 (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3 3. A Network Based Sliding Window . . . . . . . . . . . . . . . . 3 4. Bonding De-Activation . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Bandwidth aggregation capabilities across multiple Internet access links can significantly improve end users' Quality of Experience. Lots of service providers who possess multiple access networks are about to deploy or have already deployed the bandwidth aggregation capabilities. There are various enabling techniques arising to address bandwidth aggregation issues [Problem]. Among them, tunneling techniques are promising since the network-based requirement can be fulfilled easily. To achieve bandwidth aggregation, two tunnels are to be bonded together to form a single logical tunnel in between the access and aggregation equipments. When the bandwidth of the primary tunnel fills, the secondary tunnel can be used to accommodate the excessive load, while end users are supposed not to be aware of the shifting. Flow control is a desirable feature for bandwidth aggregation. In this document, TCP-like sliding window mechanism is integrated into the tunnel to handle the packet delay, loss and network congestion. However, considering the overhead that may be introduced into the tunnel, the transportation utilities used here will not cover a full set of TCP functions. In the practical deployment, the quality of the two bonded tunnels Mingui Zhang, et al Expires September 22, 2016 [Page 2] INTERNET-DRAFT TCP in Bonding Tunnels March 21, 2016 may become un-comparable. The bonding mode will be deactivated and user's traffic will be carried using the primary tunnel only. From calculating of the Adaptive Time-Out in the flow control, operators can judge whether the bonding mode should be deactivated. 2. Acronyms and Terminology Hybrid Access: The bonding of multiple access connections based on heterogeneous technologies (e.g., DSL and LTE) that are provided by the same carrier. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. A Network Based Sliding Window This document equips bonded tunnels with the well-known sliding window mechanism, which used to be a well-know TCP utility, to handle packet loss, packet delay and congestions introduced by the bonding tunnel. Compared to the sliding windows that are implemented on end- systems, this document specifies a network based sliding window mechanism. In order to realize the sliding window mechanism, sequence number and acknowledgement number are required. Note that the sequence number specified in this document is used to number packets sent on each individual tunnel. It is different from the sequence number that is used for packet reordering for the entire bonding tunnel [GREbond]. However, the two sequence numbers maybe concatenated to use the 4- octet Sequence Number field of the GRE header [GREbond]. The sequence number for the entire bonding tunnel uses the higher order two octets while the sequence number of the individual tunnel uses the lower order two octets. Based on this sequence number and acknowledgement number, retransmission could be realized. However, considering the heavy overhead that might be caused, HCPE and HAG will not perform retransmission. Retransmission might be realized in accompanied TCP proxies or accelerators, but it is out the scope of this document. The individual tunnels will merely adopt sliding window mechanism to moderate the rate at which the data is being transmitted. To support such a mechanism, the HCPE and HAG devices are required to implement a sending window. Sequence numbers and acknowledgement numbers are maintained per individual tunnels. Sequence numbers have to be piggybacked on data packets while acknowledgement numbers can be sent separately from Mingui Zhang, et al Expires September 22, 2016 [Page 3] INTERNET-DRAFT TCP in Bonding Tunnels March 21, 2016 data packets. Each bonding tunnel is treated as a constant long-live session. Sliding window protocol of [RFC2637] will be used as the basis. The following changes to RFC 2637 are required. (Section 4.2.4. Window Overflow) When a receiver's window overflows with too many incoming packets, the receiver immediately starts to digest the packets in the window and put them into the reordering buffer, even if there are missing packets. This process continues until excess packets are accommodated. When the secondary transmission window fills, no more traffic should be distributed to the secondary tunnel. Packets will enter the primary transmission window. (Section 4.2.5. Multi-packet Acknowledgment) Each packet is acknowledged as it enters the reordering buffer of the bonding tunnel. When the receiving window overflows, packets are digested even if there are missing packets with lower sequence number. At that point, those digested packets will be acknowledged as well. (Section 4.3. Out-of-sequence Packets) Out of sequence packets are not dropped. Instead, they will be digested and enter the reordering buffer of the bonding tunnel. For these out-of-sequence packets, no acknowledgement will be sent. (Section 4.4.1. Calculating Adaptive Acknowledgment Time-Out) When a time-out occurs for the secondary tunnel, the sending device will not stop distributing packets onto the secondary tunnel as long as a good throughput is promised (i.e., the transmission window does not fill), unless the difference of the ATOs of the two tunnels exceeds the configured MaxDiffTimeOut. In the case that the difference of ATOs exceeds MaxDiffTimeOut or the secondary transmission window fills, no packets will be distributed to the secondary tunnel. Packets remained in the secondary transmission window will be moved to the primary transmission window. 4. Bonding De-Activation In the practical deployment, the secondary connection might suffer from large latency, jitter and high packet loss rate. In the bonding tunnel, packets are distributed onto both primary and secondary tunnels at one end and then recombined again in a buffer at the receiver. If the secondary GRE tunnel suffers, the entire bonding tunnel will suffer as well due to the recombination function. For example, assume packet 1 is distributed onto the secondary GRE tunnel while packet 2 is distributed onto the primary GRE tunnel. If packet 1 is delayed by 100 ms, even packet 2 arrives at the recombination butter at the first ms, it has to remain in the buffer awaiting for 99 ms for packet 1. Mingui Zhang, et al Expires September 22, 2016 [Page 4] INTERNET-DRAFT TCP in Bonding Tunnels March 21, 2016 Deployment experiences show that the TCP throughput of the bonding tunnel might be greatly reduced due to the downgrade or disruption of the secondary tunnel. Hence, monitoring the performance of the secondary tunnel is required. Based on the monitoring, when the performance of the two links are comparable operators will remain the bonding mode open. Otherwise, when the monitored performance parameters do not meet their predefined requirements, the bonding mode will be de-activated so that the HCPE and HAG only use the primary connection. As specified in Section 3, the calculation of the Adaptive Acknowledgment Time-Out provides such kind of monitoring. 5. Security Considerations Unless the payload data and control messages carried in the tunnels are cryptographically protected, they can be captured and read or modified. Attackers may make up bogus sequence numbers and acknowledge numbers to cause replay or deny of service attacks. 6. IANA Considerations No new registration is required to be allocated from IANA. RFC editor, please remove this section before its publication. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999, . [GREbond] Leymann, N., Heidemann, C. , et al, "GRE Tunnel Bonding", draft-zhang-gre-tunnel-bonding, Work in Progress. 7.2. Informative References [Problem] Cullen, M., et al, "Problem Statement: Bandwidth Aggregation for Internet Access", Work in Progress, draft- zhang-banana-problem-statement, Work in Progress. Mingui Zhang, et al Expires September 22, 2016 [Page 5] INTERNET-DRAFT TCP in Bonding Tunnels March 21, 2016 Author's Addresses Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China Email: zhangmingui@huawei.com Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21-27 Berlin 10781 Germany Phone: +49-170-2275345 EMail: n.leymann@telekom.de Cornelius Heidemann Deutsche Telekom AG Heinrich-Hertz-Strasse 3-7 Darmstadt 64295 Germany Phone: +4961515812721 Email: heidemannc@telekom.de Margaret Cullen Painless Security 14 Summer St. Suite 202 Malden, MA 02148 United States Email: margaret@painless-security.com Mingui Zhang, et al Expires September 22, 2016 [Page 6]