idnits 2.17.1 draft-li-quic-optimizing-ack-in-wlan-01.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 16, 2020) is 1229 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-27 == Outdated reference: A later version (-04) exists of draft-fairhurst-quic-ack-scaling-03 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC T. Li 3 Internet-Draft K. Zheng 4 Intended status: Experimental R. Jadhav 5 Expires: May 20, 2021 J. Kang 6 Huawei 7 November 16, 2020 9 Optimizing ACK mechanism for QUIC 10 draft-li-quic-optimizing-ack-in-wlan-01 12 Abstract 14 The dependence on frequent acknowledgments (ACKs) is an artifact of 15 current transport protocol designs rather than a fundamental 16 requirement. This document analyzes the problems caused by 17 contentions and collisions on wireless medium between data packets 18 and ACKs in WLAN and it proposes an ACK mechanism that minimizes the 19 intensity of ACK Frame in QUIC, improving the performance of 20 transport layer connection. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 20, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Overview of Standards on ACK Mechanism . . . . . . . . . . . 3 59 4. Optimized ACK Mechanism for QUIC . . . . . . . . . . . . . . 4 60 4.1. Reducing ACK intensity . . . . . . . . . . . . . . . . . 4 61 4.2. OWD-based RTTmin estimation . . . . . . . . . . . . . . . 5 62 4.3. Sender-Side Operation . . . . . . . . . . . . . . . . . . 7 63 4.4. Receiver-side Operation . . . . . . . . . . . . . . . . . 7 64 4.5. Generating ACK . . . . . . . . . . . . . . . . . . . . . 8 65 4.6. Modification to QUIC Protocol . . . . . . . . . . . . . . 8 66 4.6.1. Transport Parameter: ack-intensity-support . . . . . 8 67 4.6.2. ACK-INTENSITY Frame . . . . . . . . . . . . . . . . . 9 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 7.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Requirements Language 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 2. Problem Statement 83 High-throughput transport over wireless local area network (WLAN) 84 becomes a demanding requirement with the emergence of 4K wireless 85 projection, VR/AR-based interactive gaming, and more. However, the 86 shared nature of the wireless medium induces contention between data 87 transport and backward signaling, such as acknowledgement. ACKs 88 share the same medium route with data packets, causing similar medium 89 access overhead despite the much smaller size of the ACKs. 90 Contentions and collisions, as well as the wasted wireless resources 91 by ACKs, lead to significant throughput decline on the data path. 93 3. Overview of Standards on ACK Mechanism 95 [QUIC-TRANSPORT] specifies a simple delayed ACK mechanism that a 96 receiver can send an ACK for every other packet, and for every packet 97 when reordering is observed, or when the max_ack_delay timer expires. 98 However, this ACK mechanism may not match the number of ACKs to the 99 transport's required intensity under different network conditions. 100 For example, when the data throughput of a WLAN transport is 101 extremely high, QUIC will generate a large number of ACKs. In this 102 case, minimizing the ACK intensity of QUIC is not only a win for data 103 throughput improvement but also a win for energy and CPU efficiency. 105 RFC 1122 [RFC1122] and RFC 5681 [RFC5681] were two core functionality 106 standards that introduced delayed ACK, which was the default 107 acknowledgment mechanism in most Linux distributions. RFC 4341 108 [RFC4341] and RFC 5690 [RFC5690] described an acknowledgment 109 congestion control mechanism in which the minimum ACK frequency 110 allowed is twice per send window. RFC 3449 [RFC3449] discussed the 111 imperfection and variability of TCP's acknowledgment mechanism 112 because of asymmetric effects and recommended scaling ACK frequency 113 as a mitigation to these effects. These RFCs reveal that the 114 dependence on frequent ACKs is an artifact of current transport 115 protocol designs rather than a fundamental requirement. Based on 116 this insight, some work-in-progress IETF drafts have paid great 117 attention to ACK scaling technologies in both TCP and QUIC working 118 groups. 120 First of all, [ACK-PULL] proposed the TCP ACK pull mechanism, which 121 allows a sender to request the ACK for a data segment to be sent 122 without additional delay by the receiver. This helps in some cases 123 when the delayed ACKs degrade transport performance. 125 Instead of pulling more ACKs, [QUIC-SCALING] recommended that 126 reducing the ACK frequency by sending an ACK for at least every 10 127 received packets and [QUIC-SATCOM] recommended an ACK frequency of 128 four ACKs every round-trip time (RTT), aiming to reduce link 129 transmission costs for asymmetric paths. 131 Different from using an empirical value of ACK frequency, instead, 132 this draft aims to improve the scalability by proposing the Tame ACK 133 (TACK), whose frequency is a function of bandwidth-delay product of 134 network connections. [IYENGAR-ACK] has proposed an extension of 135 sender controlled ACK-FREQUENCY frame for QUIC, which is possible to 136 be reused to help the sender sync the dynamically adjusted TACK 137 frequency with the receiver in this case. 139 4. Optimized ACK Mechanism for QUIC 141 4.1. Reducing ACK intensity 143 ACK intensity can be quantified by the unit of Hz, i.e., number of 144 ACKs per second. Byte-counting ACK and periodic ACK are two 145 fundamental ways to reduce ACK intensity on the transport layer. 147 1. Byte-counting ACK: ACK intensity is controlled by sending an ACK 148 for every L (L >= 2) incoming full-sized packets, in which the packet 149 size equals to the Max Packet Size (set in the max_packet_size 150 parameter in QUIC). The intensity of byte-counting ACK (f_b) is 151 proportional to data throughput (bw): 153 f_b = bw/L*max_packet_size (1) 155 In general, f_b can be reduced by setting a large value of L. 156 However, for a given L, f_b increases with bw. This means when data 157 throughput is extremely high, the ACK intensity still might be 158 comparatively large. In other words, the intensity of byte-counting 159 ACK changes proportionately with bandwidth. 161 2. Periodic ACK: Byte-counting ACK's unbounded intensity can be 162 attributed to the coupling between ACK sending and packet arrivals. 163 Periodic ACK can decouple ACK intensity from packet arrivals, 164 achieving a bounded ACK intensity when bw is high. The intensity of 165 periodic ACK (f_pack) is: 167 f_pack = 1/alpha (2) 169 Where alpha is the time interval between two ACKs and is a function 170 of RTT. However, when bw is extremely low, the ACK intensity is 171 always as high as that in the case of a high throughput. In other 172 words, the intensity of periodic ACK is unadaptable to bandwidth 173 change, which wastes resources. 175 Combining these two ways, the minimum ACK intensity in a QUIC 176 connection can be set as f_quic = min{f_b,f_pack}. Through Equations 177 (1) and (2), we have 179 f_quic = min{bw/(L*max_packet_size), 1/alpha} (3) 181 We set alpha = RTTmin/beta, which means sending beta ACKs per RTTmin. 182 RTTmin is the minimum RTT observed for a given network path. As a 183 consequence, the minimum ACK intensity in a QUIC connection can be 184 given as follow: 186 f_quic = min{bw/(L*max_packet_size), beta/RTTmin} (4) 187 where beta indicates the number of ACKs per RTT, and L indicates the 188 number of full-sized data packets counted before sending an ACK. To 189 minimize the ACK intensity, a smaller beta or a larger L is expected. 190 Sara Landstrom et al. has given a lower bound of beta in [Sara], 191 i.e., beta >= 2. An upper bound of L can also be derived according 192 to the loss rate on the data path (plr_data) and the ack path 193 (plr_ack), i.e., L <= feedback_info/(plr_data*plr_ack), where 194 feedback_info denotes the amount of information carried by an ACK 196 Qualitatively, periodic ACK is applied when bandwidth-delay product 197 (bdp) is large (i.e., bdp >= beta*L* max_packet_size), and byte- 198 counting ACK is applied when bdp is small (i.e., bdp < beta*L* 199 max_packet_size). 201 In terms of a transport with a large bdp, beta = 2 should be 202 sufficient to ensure utilization, but the large bottleneck buffer 203 (i.e., one bdp) makes it necessary to acknowledge data more often. 204 In general, the minimum send window (SWNDmin) can be roughly 205 estimated as follow: 207 SWNDmin = beta*bdp/(beta-1) (5) 209 Ideally, the bottleneck buffer requirement is decided by the minimum 210 send window, i.e., SWNDmin - bdp. Since doubling the ACK frequency 211 reduces the bottleneck buffer requirement substantially from 1 bdp to 212 0.33 bdp, beta = 4 is RECOMMENDED to provide redundancy [Sara], being 213 more robust in practice. 215 4.2. OWD-based RTTmin estimation 217 In this document, the RTTmin is the minimum RTT samples observed at 218 the sender for a given network path during a period of time, and 219 OWDmin is the minimum OWD samples observed on the same network path 220 during a period of time. 222 When multiple packets carrying departure timestamps are transported 223 between endpoints via the same path, an RTT of this path can be 224 sampled at the sender upon receiving an ACK frame. However, when 225 sending fewer ACK frames, more data packets might be received during 226 the ACK interval, generating only one RTT sample among multiple 227 packets is likely to result in biases. For example, a larger minimum 228 RTT estimate. In general, the higher the throughput, the larger the 229 biases. One alternative way to reduce biases can be that, each ACK 230 frame carries multiple timestamps (as well as ACK delays in 231 [QUIC-RECOVERY] for the sender to generate more RTT samples. 232 However, (1) the overhead is high, which is unacceptable especially 233 under high-bandwidth transport. Also, (2) the number of data packets 234 might be far more than the maximum number of timestamps that an ACK 235 frame is capable to carry. 237 An RTT estimation system contains a sender and a receiver. The 238 sender can hardly generate per-packet RTT samples, which is the root 239 cause of the minimum RTT estimation biases in the case of sending 240 fewer ACKs. When multiple packets carrying departure timestamps are 241 transported between endpoints via the same path , an RTT of this path 242 can be sampled at the sender upon receiving an ACK frame. However, 243 when sending fewer ACK frames, more data packets might be received 244 during the ACK interval, generating only one RTT sample among 245 multiple packets is likely to result in biases. For example, a 246 larger minimum RTT estimate. In general, the higher the throughput, 247 the larger the biases. One alternative way to reduce biases can be 248 that, each ACK frame carries multiple timestamps (as well as ACK 249 delays in [QUIC-RECOVERY]) for the sender to generate more RTT 250 samples. However, (1) the overhead is high, which is unacceptable 251 especially under high-bandwidth transport. Also, (2) the number of 252 data packets might be far more than the maximum number of timestamps 253 that an ACK frame is capable to carry. Since the receiver is capable 254 to monitor per-packet state, the one-way delay (OWD) of each packet 255 can be easily computed according to the departure timestamps (carried 256 in the packet) and the arrival timestamps of each packet. In this 257 case, QUIC SHOULD adopt the OWD-based RTTmin estimation. The 258 rationale is that the variation of OWD reflects the variation of RTT 259 over near-symmetric links. The OWD-based RTTmin estimation requires 260 the sender to record the departure timestamp in each ack-eliciting 261 packet. Meanwhile, at the receiver, the per-packet OWD samples 262 SHOULD be computed upon packet arrivals and a function of computing 263 the minimum OWD SHOULD be newly added. The receiver then generates 264 an ACK frame to the sender, in which the ACK delay and departure 265 timestamp for the packet that achieves the minimum OWD is reported. 266 The ACK delay is defined as the delay incurred between when the 267 packet is received and when the ACK frame is sent. Based on the 268 information reported by the incoming ACK frames and the ACK arrival 269 timestamps, the sender can generate RTT samples and then compute 270 RTTmin accordingly. 272 In this document, RTTmin is used to update the ACK intensity. In 273 general, RTTmin can also be used by other modules. For example, some 274 congestion controllers depends on RTTmin to estimate the congestion 275 window [Neal]. RTTmin is also used by QUIC loss detection to reject 276 implausibly small rtt samples [QUIC-RECOVERY]. 278 4.3. Sender-Side Operation 280 According to Formula (4), the run-time ACK intensity in QUIC are 281 decided by bw, and RTTmin. Generally, the RTTmin and bw are 282 calculated at the sender. 284 Before estimating the RTTmin, the RTT samples should be computed 285 based on the ACK frames collected during a period of time. Assume 286 that a packet is sent by the sender at time t_1 and arrives at time 287 t_3, and the ACK frame is sent at time t_4. The ACK delay can be 288 computed at the receiver. For example, the receiver computes the ACK 289 delay delta_t = t_4 - t_3, and syncs the ACK delay to the sender via 290 an ACK frame. The ACK delay can also be computed at the sender. For 291 example, the receiver directly syncs an ACK frame carrying t_4 and 292 t_3 to the sender, the sender then computes the ACK delay delta_t = 293 t_4 - t_3. 295 The sender therefore computes an RTT sample according to delta_t, 296 t_1, and the arrival time (t_2) of the ACK frame, i.e., RTT_sample = 297 t_2 - t_1 - delta_t. Measuring delta_t at the receiver assures an 298 explicit correction for a more accurate RTT estimate. RTT samples 299 SHOULD be smoothed using exponentially weighted moving average (EWMA) 300 as specified in [RFC6298]. The sender then computes the RTTmin 301 according to these RTT samples during a period of time. 303 The bw estimation can be acquired in a similar manner to BBR [Neal]. 304 Since minimizing the ACK intensity induces excessive ACK delay, the 305 value of bw may be the average value over a long period of time. 306 However, the biases introduced in ACK intensity computation is 307 limited. 309 After computing the f_quic, the sender periodically syncs it to the 310 receiver to update the intensity of ACK Frame by sending a new ACK- 311 INTENSITY frame. 313 The sender SHOULD generate an ACK-INTENSITY frame on a regular basis. 314 For example, when the change of f_quic exceeds a threshold, the ACK- 315 INTENSITY frame should be sent to update the ACK intensity in time. 316 The interval of ACK-INTENSITY frame can also be set according to the 317 update window of RTTmin and bw. 319 4.4. Receiver-side Operation 321 Currently, the QUIC receiver reports ACK delays for only the largest 322 acknowledged packet in an ACK frame, hence an RTT sample is generated 323 using only the largest acknowledged packet in the received ACK frame. 324 For a more accurate RTTmin estimate when sending fewer ACK frames, 325 QUIC SHOULD adopt the OWD-based RTTmin estimation. The OWD-based 326 RTTmin estimation requires the QUIC receiver to filter the departure 327 timestamp for the packet that achieves the minimum OWD during the 328 interval between two ACK frames and report the ACK delay of this 329 packet. Whether redefining the meaning of ACK delay or not, it 330 depends on the negotiation between endpoints of the QUIC connection. 332 Upon packet arrivals, the receiver is capable to generate per-packet 333 OWD samples according to the difference between packet departure 334 timestamp and packet arrival timestamp. The receiver then computes 335 the minimum OWD by comparing the per-packet OWD samples. The OWD 336 estimation does not require clock synchronization here because the 337 relative values are adopted. 339 Afterwards, based on the ACK delay and the departure timestamp 340 corresponding to the packet that achieves the minimum OWD, the sender 341 calculates the RTT of this packet as a minimum RTT sample. 342 Ultimately, the minimum RTT is computed according to these minimum 343 RTT samples. 345 The ACK Delay field SHOULD be carried in the ACK Frame. Other fields 346 carried in the ACK frame have the same meaning as defined in 347 [QUIC-RECOVERY]. 349 The receiver adopts the newly updated ACK intensity once it receives 350 the ACK-INTENSITY frame from the sender. 352 4.5. Generating ACK 354 The newly proposed ACK mechanism SHOULD be applied when there is no 355 out-of-order delivery. When reordering happens, the ACK Frame SHOULD 356 be generated immediately. 358 4.6. Modification to QUIC Protocol 360 4.6.1. Transport Parameter: ack-intensity-support 362 A new field named ack-intensity-support should be added for 363 negotiation between both parties whether starting the dynamic ACK 364 intensity function in QUIC connection. The endpoints sends this 365 parameter during handshakes. Only when both parties agree, ACK 366 intensity refreshment can be adopted. 368 ack-intensity-support (0x XX):This parameter has two values (0 or 1) 369 specifying whether the sending endpoint is willing to adopt ACK 370 intensity refreshment. When the value is set as 1, it means that the 371 sending endpoint want to start ACK intensity refreshment during 372 connection. When the value is set as 0, it means that the sending 373 endpoint does not support this function. 375 4.6.2. ACK-INTENSITY Frame 377 An ACK-INTENSITY frame is shown in Figure 1. 379 0 1 2 3 380 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | 0x b0(i) ... 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Sequence Number(i) ... 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | ACK Intensity (i) ... 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Figure 1: ACK-INTENSITY Frame 391 An ACK-INTENSITY frame contains the following fields: 393 Sequence Number: A variable-length integer indicating the sequence 394 number assigned to the ACK-INTENSITY frame by the sender. 396 ACK Intensity: A variable-length integer indicating the updated 397 f_quic calculated by the sender. 399 ACK-INTENSITY frames are ack-eliciting. However, their loss does not 400 require retransmission. 402 Multiple ACK-INTENSITY frames SHOULD be generated by the sender 403 during a connection to notify the receiver the variation of ACK 404 intensity requirement under network dynamics. 406 5. Security Considerations 408 TBD 410 6. IANA Considerations 412 The value for ack-intensity-support transport parameter and ACK- 413 INTENSITY frame should be allocated. 415 7. References 417 7.1. Normative References 419 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 420 Communication Layers", STD 3, RFC 1122, 421 DOI 10.17487/RFC1122, October 1989, 422 . 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, 426 DOI 10.17487/RFC2119, March 1997, 427 . 429 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 430 Sooriyabandara, "TCP Performance Implications of Network 431 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 432 December 2002, . 434 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 435 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 436 Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March 437 2006, . 439 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 440 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 441 . 443 [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 444 Acknowledgement Congestion Control to TCP", RFC 5690, 445 DOI 10.17487/RFC5690, February 2010, 446 . 448 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 449 "Computing TCP's Retransmission Timer", RFC 6298, 450 DOI 10.17487/RFC6298, June 2011, 451 . 453 7.2. Informative References 455 [ACK-PULL] 456 Gomez, C., Ed. and J. Crowcroft, Ed., "TCP ACK Pull", 457 draft-gomez-tcpm-ack-pull-01 (work in progress), November 458 2019. 460 [IYENGAR-ACK] 461 Iyengar, J., Ed. and I. Swett, Ed., "Sender Control of 462 Acknowledgement Delays in QUIC", draft-iyengar-quic- 463 delayed-ack-02 (work in progress), November 2020. 465 [Neal] Cardwell, N., Cheng, Y., Gunn, C. S., Yeganeh, S. H., and 466 V. Jacobson, "BBR: Congestion-based congestion control", 467 ACM QUEUE 14(5):20-53, 2016. 469 [QUIC-RECOVERY] 470 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 471 and Congestion Control", draft-ietf-quic-recovery-27 (work 472 in progress), February 2020. 474 [QUIC-SATCOM] 475 Kuhn, N., Ed., Fairhurst, G., Ed., Border, J., Ed., and E. 476 Stephan, Ed., "QUIC for SATCOM", draft-kuhn-quic-4-sat-06 477 (work in progress), October 2020. 479 [QUIC-SCALING] 480 Fairhurst, G., Ed., Custura, A., Ed., and T. Jones, Ed., 481 "Changing the Default QUIC ACK Policy", draft-fairhurst- 482 quic-ack-scaling-03 (work in progress), September 2020. 484 [QUIC-TRANSPORT] 485 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 486 Multiplexed and Secure Transport", draft-ietf-quic- 487 transport-27 (work in progress), March 2020. 489 [Sara] Landstrom, S. and L. Larzon, "Reducing the tcp 490 acknowledgment frequency", ACM SIGCOMM CCR 37(3):5-16, 491 2007. 493 Authors' Addresses 495 Tong Li 496 Huawei 497 D2-03,Huawei Industrial Base 498 Longgang District 499 Shenzhen 500 China 502 Email: li.tong@huawei.com 504 Kai Zheng 505 Huawei 506 Information Road, Haidian District 507 Beijing 508 China 510 Email: kai.zheng@huawei.com 511 Rahul Arvind Jadhav 512 Huawei 513 D2-03,Huawei Industrial Base 514 Longgang District 515 Shenzhen 516 China 518 Email: rahul.jadhav@huawei.com 520 Jiao Kang 521 Huawei 522 D2-03,Huawei Industrial Base 523 Longgang District 524 Shenzhen 525 China 527 Email: kangjiao@huawei.com