[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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


   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 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

   The list of Internet-Draft Shadow Directories can be accessed at

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",
   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

   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

   (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, <http://www.rfc-

   [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, <http://www.rfc-

   [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

   Email: zhangmingui@huawei.com

   Nicolai Leymann
   Deutsche Telekom AG
   Winterfeldtstrasse 21-27
   Berlin  10781

   Phone: +49-170-2275345
   EMail: n.leymann@telekom.de

   Cornelius Heidemann
   Deutsche Telekom AG
   Heinrich-Hertz-Strasse 3-7
   Darmstadt  64295

   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]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/