Network Working Group J. You
Internet-Draft M. Zhang
Intended status: Informational Huawei Technologies
Expires: September 22, 2016 N. Leymann
C. Heidemann
Deutsche Telekom AG
March 21, 2016

Traffic Distribution for GRE Tunnel Bonding
draft-you-traffic-distribution-for-bonding-00

Abstract

GRE (Generic Routing Encapsulation) Tunnel Bonding as an L3 overlay tunneling mechanism is used for Hybrid Access (HA) bonding between HCPE (Hybrid Customer Premises Equipment) and HAG (Hybrid Access Gateway). The bonding performance depends upon the performance for each individual link. This document specifies a trying overflow mechanism to avoid the bonding performance downgrading due to the situation that an individual link is disrupted or its quality downgrages too much so that the bonding is no longer applicable.

Requirements Language

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

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on September 22, 2016.

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

Service providers want to supply a higher throughput for their subscribers to provide a better customer experience, especially in those cases where customers can only be offered with a low bitrate DSL access. Bonding of fixed broadband and 3GPP access networks becomes desirable. [I-D.zhang-gre-tunnel-bonding] proposes a GRE (Generic Routing Encapsulation) tunnel bonding mechanism for bonding of DSL (Digital Subscriber Line) connection and LTE (Long Term Evolution) connection. An example of deployment scenario is illustrated in Figure 1. The Hybrid Access (HA) bonded connection is established between the HCPE (Hybrid Customer Premises Equipment), in the customer premises network, and the HAG (Hybrid Access Gateway), on the service provider's network [WT-348].

               +------+ LTE GRE Tunnel  +-------+
+---------+    |      +-----------------+       |  Internet
|User     +----+ HCPE |                 |  HAG  +-----
|Equipment|    |      +-----------------+       |
+---------+    +------+ DSL GRE Tunnel  +-------+

               Figure 1: GRE Tunnel Bonding

The bonding should not be enabled if the bonding performance is worse than DSL only. This document proposes a traffic distribution algorithm named trying overflow to improve the bonding performance.

2. Terminology

2.1. Abbreviations and acronyms

2.2. Definitions

3. TCP Throughput Measurement and Issues

The Quality of Experience (QoE) on a hybrid access service depends upon the performance of each individual link. Generally, TCP Throughput (T) for a link can be measured as:

Throughput <= min (BW, WindowSize/RTT, MSS/(RTT*sqrt(p)) )

While for hybrid access,

RTT = max(RTT1, RTT2)
p = w1*p1+w2*p2

Therein,

When LTE link becomes congested, the latency may reach up to 400 ms; while the normal latency on DSL may only be 10 ms. According to the formula above, the TCP throughput for the hybrid access would be worse than DSL link only assuming p1 = p2.

4. Traffic Distribution Algorithm

Principle: Traffic distribution over DSL is prior to traffic distribution over LTE. The bonding mode would be enabled if the bonding performance is better than DSL only. Otherwise the bonding should not be enabled.

CAR (Committed Access Rate) with two token buckets is used to distribute traffic flows on HA-compliant nodes.

 +-------+  (RTT2, p2, T2)       +-------+
 |       |  LTE GRE Tunnel       |       |
 |       +-----------------------+       |
 | HPCE  |                       |  HAG  |
 |       |          +-----+      |       |
 |       +----------+BRAS +------+       |
 +-------+          +-----+      +-------+
             DSL GRE Tunnel
             (RTT1, p1, T1)

       Figure 2: Deployment Scenario

1. Start DSL only, and measure RTT1, p1 and T1 periodically; get <RTT1_min, p1_min>, <T1_max, RTT1_t1max, p1_t1max>. Here RTT1_t1max refers to the RTT when the throughput reaches maximum (T1_max) in a period. Likewise, p1_t1max refers to the p when the throughput reaches maximum (T1_max) in a period.

2. Estimate the usage of DSL according to RTT1 and P1; If there's no congestion (i.e. RTT1=RTT1_min and p1=p1_min), bonding is not enabled.

3. If DSL is congested (i.e. RTT1>RTT1_min or p1>p1_min), start the "trying overflow" procedure (detailed in Section 5).

5. Trying Overflow Mechanism

The "Trying Overflow" mechanism is implemented using the token bucket mechanism on, as shown in Figure 3.

        |
        |CIR2=LTE_MIN
        |
       \|/
    +---+----+
    +--------+
    |        |  Mark color
    |Trying  |  (Yellow, #1)
    |Overflow+---------------------+
    |Bucket  |                     |
    |        |                    \|/
    +---+----+                 +---+----+
        |Mark color            +--------+ Mark color
        | (Green)              |        | (Yellow, #2)
       \|/                     |        +--------------+
   +----------+                |DSL     | CIR1=T1_max  |
   |Forward to|                |Bucket  |             \|/
   |LTE tunnel|                |        |         +----------+
   +----------+                +---+----+         |Forward to|
                       Mark color  |              |LTE tunnel|
                        (Green)   \|/             +----------+
                              +----------+
                              |Forward to|
                              |DSL tunnel|
                              +----------+

                   Figure 3: Trying Overflow

• Trying Overflow Bucket: In this step, all the incoming traffic will be distributed to the trying overflow bucket. Its CIR can be set to LTE_MIN.

• DSL Bucket: Its CIR can be set to T1_max. The green packets will be distributed into DSL tunnel, and yellow packets of #2 will be distributed into LTE tunnel.

Theoretically, if the LTE tunnel is suitable for bonding, the bonding TCP throughput T12 will increase continuously; and will exceed T1_max immediately. Yellow packets of #2 can be continuously observed obviously in a period of time.

6. Overbooking Considerations

DSL bandwidth can be overbooked on the BRAS (Broadband Remote Access Server). Overbooking may cause long delay or high packet loss rate.

When bandwidth downgrading happens on the BRAS due to overbooking, the CIR of the DSL link needs to be decreased. At that time, the bonding performance is worse than using DSL only and the DSL link is congested.

When the bandwidth is restored, the CIR of the DSL link needs to be increased. At that time, the bonding performance improves, and the congestion on the DSL link can be relieved.

7. Security Considerations

TBD.

8. References

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

8.2. Informative References

, "
[I-D.zhang-gre-tunnel-bonding] Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B. and M. Cullen, GRE Tunnel Bonding", Internet-Draft draft-zhang-gre-tunnel-bonding-01, October 2015.
[WT-348]BBF WT-348 Part-A: Hybrid Access for Broadband Networks", 12 2015.

Authors' Addresses

Jianjie You Huawei Technologies 101 Software Avenue, Yuhuatai District Nanjing, 210012 China EMail: youjianjie@huawei.com
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 EMail: n.leymann@telekom.de
Cornelius Heidemann Deutsche Telekom AG Heinrich-Hertz-Strasse 3-7 Darmstadt , 64295 Germany EMail: heidemannc@telekom.de