idnits 2.17.1 draft-you-traffic-distribution-for-bonding-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 2951 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-zhang-gre-tunnel-bonding-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. You 3 Internet-Draft M. Zhang 4 Intended status: Informational Huawei Technologies 5 Expires: September 22, 2016 N. Leymann 6 C. Heidemann 7 Deutsche Telekom AG 8 March 21, 2016 10 Traffic Distribution for GRE Tunnel Bonding 11 draft-you-traffic-distribution-for-bonding-00 13 Abstract 15 GRE (Generic Routing Encapsulation) Tunnel Bonding as an L3 overlay 16 tunneling mechanism is used for Hybrid Access (HA) bonding between 17 HCPE (Hybrid Customer Premises Equipment) and HAG (Hybrid Access 18 Gateway). The bonding performance depends upon the performance for 19 each individual link. This document specifies a trying overflow 20 mechanism to avoid the bonding performance downgrading due to the 21 situation that an individual link is disrupted or its quality 22 downgrages too much so that the bonding is no longer applicable. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 22, 2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Abbreviations and acronyms . . . . . . . . . . . . . . . 3 67 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. TCP Throughput Measurement and Issues . . . . . . . . . . . . 4 69 4. Traffic Distribution Algorithm . . . . . . . . . . . . . . . 4 70 5. Trying Overflow Mechanism . . . . . . . . . . . . . . . . . . 6 71 6. Overbooking Considerations . . . . . . . . . . . . . . . . . 7 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 8.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 Service providers want to supply a higher throughput for their 81 subscribers to provide a better customer experience, especially in 82 those cases where customers can only be offered with a low bitrate 83 DSL access. Bonding of fixed broadband and 3GPP access networks 84 becomes desirable. [I-D.zhang-gre-tunnel-bonding] proposes a GRE 85 (Generic Routing Encapsulation) tunnel bonding mechanism for bonding 86 of DSL (Digital Subscriber Line) connection and LTE (Long Term 87 Evolution) connection. An example of deployment scenario is 88 illustrated in Figure 1. The Hybrid Access (HA) bonded connection is 89 established between the HCPE (Hybrid Customer Premises Equipment), in 90 the customer premises network, and the HAG (Hybrid Access Gateway), 91 on the service provider's network [WT-348]. 93 +------+ LTE GRE Tunnel +-------+ 94 +---------+ | +-----------------+ | Internet 95 |User +----+ HCPE | | HAG +----- 96 |Equipment| | +-----------------+ | 97 +---------+ +------+ DSL GRE Tunnel +-------+ 99 Figure 1: GRE Tunnel Bonding 101 The bonding should not be enabled if the bonding performance is worse 102 than DSL only. This document proposes a traffic distribution 103 algorithm named trying overflow to improve the bonding performance. 105 2. Terminology 107 2.1. Abbreviations and acronyms 109 BRAS: Broadband Remote Access Server 111 CAR: Commit Access Rate 113 CIR: Committed Information Rate 115 HA: Hybrid Access 117 HAG: Hybrid Access Gateway 119 HCPE: Hybrid Customer Premises Equipment 121 LTE: Long Term Evolution 123 2.2. Definitions 125 Hybrid Access: The bonding of two access paths based on 126 heterogeneous technologies (e.g., DSL and LTE). 128 Hybrid Access Gateway: A logical function in the operator network 129 implementing a bonding mechanism for customer access services. 131 Hybrid Customer Premises Equipment: A CPE enhanced to support the 132 simultaneous use of both fixed broadband and 3GPP access networks. 134 Hybrid Access Gateway: A logical function in the operator network 135 implementing a bonding mechanism for customer access services. 137 3. TCP Throughput Measurement and Issues 139 The Quality of Experience (QoE) on a hybrid access service depends 140 upon the performance of each individual link. Generally, TCP 141 Throughput (T) for a link can be measured as: 143 Throughput <= min (BW, WindowSize/RTT, MSS/(RTT*sqrt(p)) ) 145 While for hybrid access, 147 RTT = max(RTT1, RTT2) 148 p = w1*p1+w2*p2 150 Therein, 152 BW: maximum bandwidth 154 WindowSize: congestion window size 156 RTT: Round Trip Time; RTT1 for DSL link, RTT2 for LTE link 158 MSS: maximum segment size (fixed for each Internet path, typically 159 1460 Bytes) 161 p: packet loss rate; p1 for DSL link, p2 for LTE link 163 w: distribution factor; w1 refers to the percentage of total 164 traffic on DSL link; w2 refers to the percentage of total traffic 165 on LTE link. 167 When LTE link becomes congested, the latency may reach up to 400 ms; 168 while the normal latency on DSL may only be 10 ms. According to the 169 formula above, the TCP throughput for the hybrid access would be 170 worse than DSL link only assuming p1 = p2. 172 4. Traffic Distribution Algorithm 174 Principle: Traffic distribution over DSL is prior to traffic 175 distribution over LTE. The bonding mode would be enabled if the 176 bonding performance is better than DSL only. Otherwise the bonding 177 should not be enabled. 179 CAR (Committed Access Rate) with two token buckets is used to 180 distribute traffic flows on HA-compliant nodes. 182 +-------+ (RTT2, p2, T2) +-------+ 183 | | LTE GRE Tunnel | | 184 | +-----------------------+ | 185 | HPCE | | HAG | 186 | | +-----+ | | 187 | +----------+BRAS +------+ | 188 +-------+ +-----+ +-------+ 189 DSL GRE Tunnel 190 (RTT1, p1, T1) 192 Figure 2: Deployment Scenario 194 1. Start DSL only, and measure RTT1, p1 and T1 periodically; get 195 , . Here RTT1_t1max 196 refers to the RTT when the throughput reaches maximum (T1_max) in a 197 period. Likewise, p1_t1max refers to the p when the throughput 198 reaches maximum (T1_max) in a period. 200 2. Estimate the usage of DSL according to RTT1 and P1; If there's no 201 congestion (i.e. RTT1=RTT1_min and p1=p1_min), bonding is not 202 enabled. 204 3. If DSL is congested (i.e. RTT1>RTT1_min or p1>p1_min), start the 205 "trying overflow" procedure (detailed in Section 5). 207 1) The bonding mode is on. Tentatively distribute a small amount 208 of traffic onto the LTE link at the initial stage, assuming CIR2 = 209 LTE_MIN (minimum committed access rate). LTE_MIN is configurable 210 and its default value is 64Kbps. 212 2) Measure the throughput of the bonded links (T12) periodically. 214 a) If T12 < T1_max and the DSL link is not congested, the 215 bonding mode should be off. 217 b) If T12 < T1_max and the DSL link is congested, the bonding 218 mode is open, the CIR adjustment (i.e. decreasing) of the DSL 219 link is triggered. 221 c) Otherwise, the bonding mode is on. Set CIR1 = T1_max, the 222 overflow traffic is distributed to LTE tunnel. 224 i. If the DSL link is not congested and T12 is increasing 225 rapidly, the CIR adjustment (i.e. increasing) of the DSL 226 link is triggered. 228 5. Trying Overflow Mechanism 230 The "Trying Overflow" mechanism is implemented using the token bucket 231 mechanism on, as shown in Figure 3. 233 | 234 |CIR2=LTE_MIN 235 | 236 \|/ 237 +---+----+ 238 +--------+ 239 | | Mark color 240 |Trying | (Yellow, #1) 241 |Overflow+---------------------+ 242 |Bucket | | 243 | | \|/ 244 +---+----+ +---+----+ 245 |Mark color +--------+ Mark color 246 | (Green) | | (Yellow, #2) 247 \|/ | +--------------+ 248 +----------+ |DSL | CIR1=T1_max | 249 |Forward to| |Bucket | \|/ 250 |LTE tunnel| | | +----------+ 251 +----------+ +---+----+ |Forward to| 252 Mark color | |LTE tunnel| 253 (Green) \|/ +----------+ 254 +----------+ 255 |Forward to| 256 |DSL tunnel| 257 +----------+ 259 Figure 3: Trying Overflow 261 o Trying Overflow Bucket: In this step, all the incoming traffic will 262 be distributed to the trying overflow bucket. Its CIR can be set to 263 LTE_MIN. 265 HA node has no knowledge of the quality of the LTE tunnel at 266 first. If the LTE tunnel is congested, the bonding may impair the 267 customer experience. So trying overflow is performed. If the 268 trying is successful, then it means the LTE tunnel can be used for 269 bonding. 271 The green packets will be distributed into the LTE tunnel, while 272 yellow packets of #1 will be put into the DSL bucket. 274 o DSL Bucket: Its CIR can be set to T1_max. The green packets will 275 be distributed into DSL tunnel, and yellow packets of #2 will be 276 distributed into LTE tunnel. 278 Theoretically, if the LTE tunnel is suitable for bonding, the bonding 279 TCP throughput T12 will increase continuously; and will exceed T1_max 280 immediately. Yellow packets of #2 can be continuously observed 281 obviously in a period of time. 283 6. Overbooking Considerations 285 DSL bandwidth can be overbooked on the BRAS (Broadband Remote Access 286 Server). Overbooking may cause long delay or high packet loss rate. 288 When bandwidth downgrading happens on the BRAS due to overbooking, 289 the CIR of the DSL link needs to be decreased. At that time, the 290 bonding performance is worse than using DSL only and the DSL link is 291 congested. 293 When the bandwidth is restored, the CIR of the DSL link needs to be 294 increased. At that time, the bonding performance improves, and the 295 congestion on the DSL link can be relieved. 297 7. Security Considerations 299 TBD. 301 8. References 303 8.1. Normative References 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 8.2. Informative References 312 [I-D.zhang-gre-tunnel-bonding] 313 Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and 314 M. Cullen, "GRE Tunnel Bonding", draft-zhang-gre-tunnel- 315 bonding-01 (work in progress), October 2015. 317 [WT-348] "BBF WT-348 Part-A: Hybrid Access for Broadband Networks", 318 12 2015. 320 Authors' Addresses 322 Jianjie You 323 Huawei Technologies 324 101 Software Avenue, Yuhuatai District 325 Nanjing 210012 326 China 328 Email: youjianjie@huawei.com 330 Mingui Zhang 331 Huawei Technologies 332 No.156 Beiqing Rd. Haidian District 333 Beijing 100095 334 China 336 Email: zhangmingui@huawei.com 338 Nicolai Leymann 339 Deutsche Telekom AG 340 Winterfeldtstrasse 21-27 341 Berlin 10781 342 Germany 344 Email: n.leymann@telekom.de 346 Cornelius Heidemann 347 Deutsche Telekom AG 348 Heinrich-Hertz-Strasse 3-7 349 Darmstadt 64295 350 Germany 352 Email: heidemannc@telekom.de