Skip to main content

BANdwidth Aggregation for interNet Access (BANANA) Discard Timer Features for Bonding Tunnel Method
draft-leymann-banana-discard-timer-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Nicolai Leymann , Cornelius Heidemann , Jun Shen , Liang Geng , Lihao Chen , Mingui Zhang , Margaret Cullen
Last updated 2017-05-23
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-leymann-banana-discard-timer-01
BANANA                                                        N. Leymann
INTERNET-DRAFT                                              C. Heidemann
Intended Status: Best Current Practice               Deutsche Telekom AG
                                                                 J. Shen
                                                  China Telecom Co., Ltd
                                                                G. Liang
                                                            China Mobile
                                                                 L. Chen
                                                                M. Zhang
                                                                  Huawei
                                                               M. Cullen
                                                       Painless Security
Expires: November 24, 2017                                  May 23, 2017

           BANdwidth Aggregation for interNet Access (BANANA)
            Discard Timer Features for Bonding Tunnel Method
                 draft-leymann-banana-discard-timer-01

Abstract

   Various tunnel based methods have been developed to realize BANdwidth
   Aggregation for interNet Access (BANANA). At the egress point of
   bonding tunnels, packets that have been delivered through different
   tunnels are reordered in a bonding reordering buffer. Along each
   tunnel, network devices may set aside buffers, which are referred as
   tunnel buffers, to cache packets as well. This document exposes that
   a time boundary, which is referred as "Discard Timer", imposed on
   tunnel buffers could improve the throughput and reliability of the
   bonding tunnels.

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
 

N. Leymann, et al      Expires November 24, 2017                [Page 1]
INTERNET DRAFT         Discard Timer for Bonding            May 23, 2017

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2017 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
   (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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Problem: Packet blocking in Tunnel Buffers  . . . . . . . . . .  3
   3. Discard Timer Feature . . . . . . . . . . . . . . . . . . . . .  5
   4. Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  7
   6. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.1. Normative References  . . . . . . . . . . . . . . . . . . .  7
     6.2. Informative References  . . . . . . . . . . . . . . . . . .  7
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7

 

N. Leymann, et al      Expires November 24, 2017                [Page 2]
INTERNET DRAFT         Discard Timer for Bonding            May 23, 2017

1. Introduction

   Various bonding tunnel technologies have been proposed to realize
   BANdwidth Aggregation for interNet Access (BANANA). Per packet
   traffic distribution is used by bonding tunnels. A reordering buffer
   is used at the egress node to restore packet disorder. It is referred
   as "bonding reordering buffer" afterwards in this document. 

   As latency difference exists between tunnels, packets transmitted
   through a "faster" tunnel have to wait in the bonding reordering
   buffer for those packets that are being transmitted through a
   "slower" tunnel. Timeout limit is the maximum time that a packet can
   stay in the bonding reordering buffer. When this limit is reached,
   packets in the bonding reordering buffer MUST be forcibly delivered
   and un-arrived packets are regarded as lost packets. TCP endpoints
   would have to retransmit these lost packets. 

   Along each tunnel, network devices use buffers to cache data packets.
   These buffers are referred as "tunnel buffers" afterwards in this
   document. For example, an eNodeB would buffer packets transmitted
   through the LTE tunnel. A tunnel buffer is usually beneficial in
   absorbing traffic bursts on a tunnel. However, if a packet's
   buffering process in the tunnel buffer takes too much time so that
   the timeout limit of the bonding reordering buffer is reached, this
   packet will be regarded as a lost packet by the egress node of the
   bonding tunnels. Still, the tunnel buffer has to process and forward
   that packet, which is unnecessary. It is worthwhile to configure a
   Discard Timer for the tunnel buffer. Therefore, network devices will
   discard packets that stay in a tunnel buffer longer than the Discard
   Timer. This action can also help TCP to adapt to the available
   sending rate more quickly. The Discard Timer features are discussed
   in this document.

1.1. Terminology

   DSL: Digital Subscriber Line

   eNodeB: Evolved Node B

   LTE: Long Term Evolution

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

2. Problem: Packet blocking in Tunnel Buffers

   Figure 2.1 illustrates a bonding tunnel operation. At the ingress
 

N. Leymann, et al      Expires November 24, 2017                [Page 3]
INTERNET DRAFT         Discard Timer for Bonding            May 23, 2017

   point, each packet is allocated with a bonding sequence number and
   distributed to either tunnel by specific load balancing algorithms.
   At the egress point, packets are recombined and reordered according
   to the bonding sequence number.

                                          Timeout Value:100ms
    +------+                                          +---+   +--------+
    | TCP  |                                   Bonding|+-+|   |  TCP   |
    |Sender|    +-+-+-+-+    .    +-+  +-+  Reordering||3||   |Receiver|
    +------+    |7|5|3|1|    .    |7|  |5|      Buffer|+-+|   +--------+
      |         +-+-+-+-+    .    +-+  +-+            +---+        ^
      |              +--->---.--Tunnel 1-->----+       ^|   +-+    |
      |              |       .                 |       |v   |1|    |
      |   +-------------+    .              +------------+  +-+    |
      +-->|Ingress Point|    .              |Egress Point|----->---+
          +-------------+    .              +------------+
                     |       .                 |
                     +--->---.--Tunnel 2-->----+
                +-+-+-+-+    .  +-+  +-+     ^|
                |8|6|4|2|    .  |8|  |6|     |v
                +-+-+-+-+    .  +-+  +-+   +-------------------+
                             .             |+-+-+.............+|
                                           ||4|2|other packets||eNodeB
                                           |+-+-+.............+|Buffer
                                           +-------------------+

                 Figure 2.1 A Bonding Tunnel Operation

   Hybrid Access of DSL and LTE is a well known use case of BANANA. As
   shown in Figure 2.1, the ingress point is HAAP(Hybrid Access
   Aggregation Point), Tunnel 1 is DSL, Tunnel 2 is LTE, the eNodeB
   buffer is on LTE(this is a tunnel buffer), the egress point is
   HG(Home Gateway) and the bonding reordering buffer is at the HG.
   Other possible tunnel buffers on DSL and LTE are omitted. The bonding
   reordering buffer has a 100 ms timeout limit.

   Assuming that the LTE tunnel has a traffic burst at this moment, and
   the queue of the eNodeB buffer is relatively long. When packet No.2
   and No.4 arrive at the eNodeB buffer, they enter the queue and wait
   for their turn to be processed and forwarded, as shown in Figure 2.1.
   Meanwhile, packet No.1 and No.3 have already reached the egress point
   and packet No.3 has entered the bonding reordering buffer to wait for
   packet No.2. If packet No.2 does not reach the egress point within
   100 ms, packet No.2 will be regarded as a lost packet and packet No.3
   will be forcibly delivered by the egress point. Data carried by
   Packet No.2 will be retransmitted by TCP afterwards. However, the
   eNodeB buffer will process and forward packet No.2 all the same,
   which is actually unnecessary because by the time packet No.2 reaches
 

N. Leymann, et al      Expires November 24, 2017                [Page 4]
INTERNET DRAFT         Discard Timer for Bonding            May 23, 2017

   the egress point, it will be discarded as a duplicate packet.

   This situation, referred as "packet blocking in tunnel buffers", may
   continually cause violation of the timeout limit of the bonding
   reordering buffer, triggering a large amount of retransmission and a
   significant decrease of sending rate. The throughput of the bonding
   tunnel could be greatly reduced, even less than the throughput of a
   single tunnel.

   RED(Random Early Detection) mechanism [RED] is one of the mechanisms
   commonly used in routers for congestion avoidance. RED monitors the
   average buffer queue size and drops incoming packets based on
   statistical probabilities if the queue size exceeds a specific
   threshold. However, if RED is implemented on eNodeB buffer in Figure
   2.1, for example, packet No.2 and No.4 will not be affected for they
   have already been in the buffer. RED may not be suitable for solving
   the problem of packet blocking in tunnel buffers.

3. Discard Timer Feature

   Discard Timer is proposed to control the queue length of tunnel
   buffers by dropping packets that have been queued for too long.

   Assuming that the timeout limit of the bonding reordering buffer is
   100 ms, so it does not make sense for packets to be queuing in a
   tunnel buffer for longer than 100 ms, unless the other tunnel
   coincidentally has a large latency at the moment. With a 100 ms
   Discard Timer imposed on the tunnel buffer, any packet that has been
   queued in the tunnel buffer for 100 ms MUST be forcibly discarded. As
   shown in Figure 3.1, after queued for 100 ms, packet No.2 and No.4
   are discarded and the queue is shortened. As a result, subsequent
   packets, such as No.6 and No.8, are probably to be processed and
   forwarded to the bonding reordering buffer in time. Therefore, the
   implementation of the Discard Timer is helpful, especially when the
   tunnel buffer queue is long. The queue length would be shorten and
   latency difference between bonding tunnels would be reduced. Hence,
   the throughput and reliability of the bonding tunnels would be
   improved.

 

N. Leymann, et al      Expires November 24, 2017                [Page 5]
INTERNET DRAFT         Discard Timer for Bonding            May 23, 2017

                 A Tunnel Buffer with a 100ms Discard-Timer imposed
                        +----------------------------------+
                        |+-+-+............................+|
                 --->---||4|2| packets from other streams ||--->---
                        |+-+-+............................+|
                     |  +----------------------------------+
     ......50ms.later|..................................................
                     v  +----------------------------------+
                        |+-+-+.......+-+-+................+|
                 --->---||8|6|       |4|2|                ||--->---
                        |+-+-+.......+-+-+................+|
                     |  +----------------------------------+
     ......50ms.later|..................................................
                     v  +----------------------------------+
                        |+...........+-+-+.......+-+-+....+|
                 --->---||           |8|6|       |4|2|    ||--->---
                        |+...........+-+-+.......+-+-+....+|
   2&4 are discarded    -----------------------------------+
   6&8 have a better chance +------------------------------+
                            |+...........+-+-+............+|
                      -->---||           |8|6|            ||--->---
                            |+...........+-+-+............+|
                            -------------------------------+

          Figure 3.1 Discard Timer Effects on a Tunnel Buffer

   It is acceptable for packets to be queuing in a tunnel buffer for
   longer than 100 ms if the other tunnel also has a large latency at
   that moment, so that the latency difference between tunnels may be
   less than 100 ms and the timeout limit of the bonding reordering
   buffer may not be violated. However, this situation indicates that
   both tunnels are being suffered from a traffic burst and the risk of
   congestion is high. With a Discard Timer implemented, some packets
   will be forcibly discarded at the tunnel buffer, earlier than TCP
   detects congestion, thus reducing the queue length as well as
   triggering a sending rate decrease and helping TCP to adapt to the
   available sending rate more quickly.

   An undersized Discard Timer may cause the discarding of delayed
   packets which might be tolerated by the bonding reordering buffer.
   So, the tunnel buffer's Discard Timer SHOULD be set right to be the
   bonding reordering buffer's timeout limit.

4. Security Considerations

   <TBD>

 

N. Leymann, et al      Expires November 24, 2017                [Page 6]
INTERNET DRAFT         Discard Timer for Bonding            May 23, 2017

5. IANA Considerations

   No IANA action is required in this document. RFC Editor: please
   remove this section before publication.

6. References

6.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-
              editor.org/info/rfc2119>.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC2890, DOI 10.17487/RFC2890, September 2000,
              <http://www.rfc-editor.org/info/rfc2890>.

   [RED]      Floyd, S., Jacobson, V., "Random Early Detection (RED)
              gateways for Congestion Avoidance", IEEE/ACM Transactions
              on Networking, DOI 10.1109/90.251892, August 1993,
              <http://www.icir.org/floyd/papers/early.twocolumn.pdf>

6.2. Informative References

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC5681, DOI 10.17487/RFC5681, September 2009,
              <http://www.rfc-editor.org/info/rfc5681>.

   [GREbond]  N. Leymann, C. Heidemann, M. Zhang, et al, "GRE Tunnel
              Bonding', draft-zhang-gre-tunnel-bonding, work in
              progress.

Authors' Addresses

   Nicolai Leymann
   Deutsche Telekom AG
   Winterfeldtstrasse 21-27
   Berlin  10781
   Germany

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

 

N. Leymann, et al      Expires November 24, 2017                [Page 7]
INTERNET DRAFT         Discard Timer for Bonding            May 23, 2017

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

   Phone: +4961515812721
   EMail: heidemannc@telekom.de

   Jun Shen
   China Telecom Co., Ltd
   109 West Zhongshan Ave, Tianhe District
   Guangzhou 510630
   P.R. China

   EMail: shenjun@gsta.com

   Geng Liang
   China Mobile
   32 Xuanwumen West Street,
   Xicheng District, Beijing, 100053,
   P.R. China

   EMail: gengliang@chinamobile.com

   Lihao Chen
   Huawei Technologies
   No.156 Beiqing Rd. Haidian District,
   Beijing 100095 
   P.R. China

   EMail: lihao.chen@huawei.com

   Mingui Zhang
   Huawei Technologies
   No.156 Beiqing Rd. Haidian District,
   Beijing 100095 
   P.R. China

   EMail: zhangmingui@huawei.com

   Margaret Cullen
   Painless Security
 

N. Leymann, et al      Expires November 24, 2017                [Page 8]
INTERNET DRAFT         Discard Timer for Bonding            May 23, 2017

   14 Summer St. Suite 202
   Malden, MA 02148
   USA

   EMail: margaret@painless-security.com

N. Leymann, et al      Expires November 24, 2017                [Page 9]