idnits 2.17.00 (12 Aug 2021) /tmp/idnits55047/draft-leymann-banana-discard-timer-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2017) is 1636 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2890' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'RFC5681' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'GREbond' is defined on line 291, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RED' == Outdated reference: draft-zhang-gre-tunnel-bonding has been published as RFC 8157 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BANANA N. Leymann 3 INTERNET-DRAFT C. Heidemann 4 Intended Status: Best Current Practice Deutsche Telekom AG 5 J. Shen 6 China Telecom Co., Ltd 7 G. Liang 8 China Mobile 9 L. Chen 10 M. Zhang 11 Huawei 12 M. Cullen 13 Painless Security 14 Expires: May 24, 2018 November 20, 2017 16 BANdwidth Aggregation for interNet Access (BANANA) 17 Discard Timer Features for Bonding Tunnel Method 18 draft-leymann-banana-discard-timer-02 20 Abstract 22 Various tunnel based methods have been developed to realize BANdwidth 23 Aggregation for interNet Access (BANANA). At the egress point of 24 bonding tunnels, packets that have been delivered through different 25 tunnels are reordered in a bonding reordering buffer. Along each 26 tunnel, network devices may set aside buffers, which are referred as 27 tunnel buffers, to cache packets as well. This document exposes that 28 a time boundary, which is referred as "Discard Timer", imposed on 29 tunnel buffers could improve the throughput and reliability of the 30 bonding tunnels. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as 40 Internet-Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Copyright and License Notice 54 Copyright (c) 2017 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Problem: Packet blocking in Tunnel Buffers . . . . . . . . . . 3 72 3. Discard Timer Feature . . . . . . . . . . . . . . . . . . . . . 5 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 Various bonding tunnel technologies have been proposed to realize 83 BANdwidth Aggregation for interNet Access (BANANA). Per packet 84 traffic distribution is used by bonding tunnels. A reordering buffer 85 is used at the egress node to restore packet disorder. It is referred 86 as "bonding reordering buffer" afterwards in this document. 88 As latency difference exists between tunnels, packets transmitted 89 through a "faster" tunnel have to wait in the bonding reordering 90 buffer for those packets that are being transmitted through a 91 "slower" tunnel. Timeout limit is the maximum time that a packet can 92 stay in the bonding reordering buffer. When this limit is reached, 93 packets in the bonding reordering buffer MUST be forcibly delivered 94 and un-arrived packets are regarded as lost packets. TCP endpoints 95 would have to retransmit these lost packets. 97 Along each tunnel, network devices (e.g. routers) use buffers to 98 cache data packets. These buffers are referred as "tunnel buffers" 99 afterwards in this document. For example, an eNodeB would buffer 100 packets transmitted through the LTE tunnel. A tunnel buffer is 101 usually beneficial in absorbing traffic bursts on a tunnel. However, 102 if a packet's buffering process in the tunnel buffer takes too much 103 time so that the timeout limit of the bonding reordering buffer is 104 reached, this packet will be regarded as a lost packet by the egress 105 node of the bonding tunnels. Still, the tunnel buffer has to process 106 and forward that packet, which is unnecessary. It is worthwhile to 107 configure a Discard Timer for the tunnel buffer. Therefore, network 108 devices will discard packets that stay in a tunnel buffer longer than 109 the Discard Timer. This action can also help TCP to adapt to the 110 available sending rate more quickly. The Discard Timer features are 111 discussed in this document. 113 1.1. Terminology 115 DSL: Digital Subscriber Line 117 eNodeB: Evolved Node B 119 LTE: Long Term Evolution 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 2. Problem: Packet blocking in Tunnel Buffers 127 Figure 2.1 illustrates a bonding tunnel operation. At the ingress 128 point, each packet is allocated with a bonding sequence number and 129 distributed to either tunnel by specific load balancing algorithms. 130 At the egress point, packets are recombined and reordered according 131 to the bonding sequence number. 133 Timeout Value:100ms 134 +------+ +---+ +--------+ 135 | TCP | Bonding|+-+| | TCP | 136 |Sender| +-+-+-+-+ . +-+ +-+ Reordering||3|| |Receiver| 137 +------+ |7|5|3|1| . |7| |5| Buffer|+-+| +--------+ 138 | +-+-+-+-+ . +-+ +-+ +---+ ^ 139 | +--->---.--Tunnel 1-->----+ ^| +-+ | 140 | | . | |v |1| | 141 | +-------------+ . +------------+ +-+ | 142 +-->|Ingress Point| . |Egress Point|----->---+ 143 +-------------+ . +------------+ 144 | . | 145 +--->---.--Tunnel 2-->----+ 146 +-+-+-+-+ . +-+ +-+ ^| 147 |8|6|4|2| . |8| |6| |v 148 +-+-+-+-+ . +-+ +-+ +-------------------+ 149 . |+-+-+.............+| 150 ||4|2|other packets||eNodeB 151 |+-+-+.............+|Buffer 152 +-------------------+ 154 Figure 2.1 A Bonding Tunnel Operation 156 Hybrid Access of DSL and LTE is a well known use case of BANANA. As 157 shown in Figure 2.1, the ingress point is HAAP(Hybrid Access 158 Aggregation Point), Tunnel 1 is DSL, Tunnel 2 is LTE, the eNodeB 159 buffer is on LTE(this is a tunnel buffer), the egress point is 160 HG(Home Gateway) and the bonding reordering buffer is at the HG. 161 Other possible tunnel buffers on DSL and LTE are omitted. The bonding 162 reordering buffer has a 100 ms timeout limit. 164 Assuming that the LTE tunnel has a traffic burst at this moment, and 165 the queue of the eNodeB buffer is relatively long. When packet No.2 166 and No.4 arrive at the eNodeB buffer, they enter the queue and wait 167 for their turn to be processed and forwarded, as shown in Figure 2.1. 168 Meanwhile, packet No.1 and No.3 have already reached the egress point 169 and packet No.3 has entered the bonding reordering buffer to wait for 170 packet No.2. If packet No.2 does not reach the egress point within 171 100 ms, packet No.2 will be regarded as a lost packet and packet No.3 172 will be forcibly delivered by the egress point. Data carried by 173 Packet No.2 will be retransmitted by TCP afterwards. However, the 174 eNodeB buffer will process and forward packet No.2 all the same, 175 which is actually unnecessary because by the time packet No.2 reaches 176 the egress point, it will be discarded as a duplicate packet. 178 This situation, referred as "packet blocking in tunnel buffers", may 179 continually cause violation of the timeout limit of the bonding 180 reordering buffer, triggering a large amount of retransmission and a 181 significant decrease of sending rate. The throughput of the bonding 182 tunnel could be greatly reduced, even less than the throughput of a 183 single tunnel. 185 RED(Random Early Detection) mechanism [RED] is one of the mechanisms 186 commonly used in routers for congestion avoidance. RED monitors the 187 average buffer queue size and drops incoming packets based on 188 statistical probabilities if the queue size exceeds a specific 189 threshold. However, if RED is implemented on eNodeB buffer in Figure 190 2.1, for example, packet No.2 and No.4 will not be affected for they 191 have already been in the buffer. RED may not be suitable for solving 192 the problem of packet blocking in tunnel buffers. 194 3. Discard Timer Feature 196 Discard Timer is proposed to control the queue length of tunnel 197 buffers by dropping packets that have been queued for too long. 199 Assuming that the timeout limit of the bonding reordering buffer is 200 100 ms, so it does not make sense for packets to be queuing in a 201 tunnel buffer for longer than 100 ms, unless the other tunnel 202 coincidentally has a large latency at the moment. With a 100 ms 203 Discard Timer imposed on the tunnel buffer, any packet that has been 204 queued in the tunnel buffer for 100 ms MUST be forcibly discarded. As 205 shown in Figure 3.1, after queued for 100 ms, packet No.2 and No.4 206 are discarded and the queue is shortened. As a result, subsequent 207 packets, such as No.6 and No.8, are probably to be processed and 208 forwarded to the bonding reordering buffer in time. Therefore, the 209 implementation of the Discard Timer is helpful, especially when the 210 tunnel buffer queue is long. The queue length would be shorten and 211 latency difference between bonding tunnels would be reduced. Hence, 212 the throughput and reliability of the bonding tunnels would be 213 improved. 215 A Tunnel Buffer with a 100ms Discard-Timer imposed 216 +----------------------------------+ 217 |+-+-+............................+| 218 --->---||4|2| packets from other streams ||--->--- 219 |+-+-+............................+| 220 | +----------------------------------+ 221 ......50ms.later|.................................................. 222 v +----------------------------------+ 223 |+-+-+.......+-+-+................+| 224 --->---||8|6| |4|2| ||--->--- 225 |+-+-+.......+-+-+................+| 226 | +----------------------------------+ 227 ......50ms.later|.................................................. 228 v +----------------------------------+ 229 |+...........+-+-+.......+-+-+....+| 230 --->---|| |8|6| |4|2| ||--->--- 231 |+...........+-+-+.......+-+-+....+| 232 2&4 are discarded -----------------------------------+ 233 6&8 have a better chance +------------------------------+ 234 |+...........+-+-+............+| 235 -->---|| |8|6| ||--->--- 236 |+...........+-+-+............+| 237 -------------------------------+ 239 Figure 3.1 Discard Timer Effects on a Tunnel Buffer 241 It is acceptable for packets to be queuing in a tunnel buffer for 242 longer than 100 ms if the other tunnel also has a large latency at 243 that moment, so that the latency difference between tunnels may be 244 less than 100 ms and the timeout limit of the bonding reordering 245 buffer may not be violated. However, this situation indicates that 246 both tunnels are being suffered from a traffic burst and the risk of 247 congestion is high. With a Discard Timer implemented, some packets 248 will be forcibly discarded at the tunnel buffer, earlier than TCP 249 detects congestion, thus reducing the queue length as well as 250 triggering a sending rate decrease and helping TCP to adapt to the 251 available sending rate more quickly. 253 An undersized Discard Timer may cause the discarding of delayed 254 packets which might be tolerated by the bonding reordering buffer. 255 So, the tunnel buffer's Discard Timer SHOULD be set right to be the 256 bonding reordering buffer's timeout limit. 258 4. Security Considerations 260 262 5. IANA Considerations 264 No IANA action is required in this document. RFC Editor: please 265 remove this section before publication. 267 6. References 269 6.1. Normative References 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, DOI 273 10.17487/RFC2119, March 1997, . 276 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 277 RFC2890, DOI 10.17487/RFC2890, September 2000, 278 . 280 [RED] Floyd, S., Jacobson, V., "Random Early Detection (RED) 281 gateways for Congestion Avoidance", IEEE/ACM Transactions 282 on Networking, DOI 10.1109/90.251892, August 1993, 283 285 6.2. Informative References 287 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 288 Control", RFC5681, DOI 10.17487/RFC5681, September 2009, 289 . 291 [GREbond] N. Leymann, C. Heidemann, M. Zhang, et al, "GRE Tunnel 292 Bonding', draft-zhang-gre-tunnel-bonding, work in 293 progress. 295 Authors' Addresses 297 Nicolai Leymann 298 Deutsche Telekom AG 299 Winterfeldtstrasse 21-27 300 Berlin 10781 301 Germany 303 Phone: +49-170-2275345 304 EMail: n.leymann@telekom.de 305 Cornelius Heidemann 306 Deutsche Telekom AG 307 Heinrich-Hertz-Strasse 3-7 308 Darmstadt 64295 309 Germany 311 Phone: +4961515812721 312 EMail: heidemannc@telekom.de 314 Jun Shen 315 China Telecom Co., Ltd 316 109 West Zhongshan Ave, Tianhe District 317 Guangzhou 510630 318 P.R. China 320 EMail: shenjun@gsta.com 322 Geng Liang 323 China Mobile 324 32 Xuanwumen West Street, 325 Xicheng District, Beijing, 100053, 326 P.R. China 328 EMail: gengliang@chinamobile.com 330 Lihao Chen 331 Huawei Technologies 332 No.156 Beiqing Rd. Haidian District, 333 Beijing 100095 334 P.R. China 336 EMail: lihao.chen@huawei.com 338 Mingui Zhang 339 Huawei Technologies 340 No.156 Beiqing Rd. Haidian District, 341 Beijing 100095 342 P.R. China 344 EMail: zhangmingui@huawei.com 346 Margaret Cullen 347 Painless Security 348 14 Summer St. Suite 202 349 Malden, MA 02148 350 USA 352 EMail: margaret@painless-security.com