idnits 2.17.1 draft-song-atr-large-resp-03.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 175: '...f ATR payload size and timer SHOULD be...' RFC 2119 keyword, line 345: '...hat in IPv4 ATR payload size SHOULD be...' RFC 2119 keyword, line 346: '...n IPv6 the value SHOULD be 1232 octets...' RFC 2119 keyword, line 477: '... it is not required that resolver MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2019) is 1869 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ATR-Github' is defined on line 394, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Song 3 Internet-Draft Beijing Internet Institute 4 Intended status: Informational S. Wang 5 Expires: September 9, 2019 Beijing Normal University 6 March 8, 2019 8 ATR: Additional Truncation Response for Large DNS Response 9 draft-song-atr-large-resp-03 11 Abstract 13 As the increasing use of DNSSEC and IPv6, there are more public 14 evidence and concerns on IPv6 fragmentation issues due to larger DNS 15 payloads over IPv6. This memo introduces an simple improvement on 16 DNS server by replying an additional truncated response just after 17 the normal fragmented response. It can be used to relieve users 18 suffering on DNS latency and failures due to large DNS response. An 19 ATR Experiment was done to show how well it works and some 20 operational issues are discussed in this memo as well. 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 September 9, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. The ATR mechanism . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Experiment on how well ATR works . . . . . . . . . . . . . . 5 59 4. Operational considerations . . . . . . . . . . . . . . . . . 6 60 4.1. ATR timer . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.2. ATR payload size . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Less aggressiveness of ATR . . . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Appendix A. Considerations on Resolver awareness of ATR . . . . 11 68 Appendix B. Revision history of this document . . . . . . . . . 11 69 B.1. draft-song-atr-large-resp-01 . . . . . . . . . . . . . . 11 70 B.2. draft-song-atr-large-resp-02 . . . . . . . . . . . . . . 12 71 B.3. draft-song-atr-large-resp-03 . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 Large DNS response is identified as a issue for a long time. There 77 is an inherent mechanism defined in [RFC1035] to handle large DNS 78 response (larger than 512 octets) by indicating (set TrunCation bit) 79 the resolver to fall back to query via TCP. Due to the fear of cost 80 of TCP, EDNS(0) [RFC6891] was proposed which encourages server to 81 response larger response instead of falling back to TCP. However, as 82 the increasing use of DNSSEC and IPv6, there are more public 83 evidence[DNSSEC-impact] and concerns on user's suffering due to 84 packets dropping caused by IPv6 fragmentation in DNS due to large DNS 85 response. 87 It is observed that some IPv6 network devices like firewalls 88 intentionally choose to drop the IPv6 packets with fragmentation 89 Headers[I-D.taylor-v6ops-fragdrop]. [RFC7872] reported more than 30% 90 drop rates for sending fragmented packets. Regarding IPv6 91 fragmentation issue due to larger DNS payloads in response, one 92 measurement [IPv6-frag-DNS] reported 35% of endpoints using 93 IPv6-capable DNS resolver can not receive a fragmented IPv6 response 94 over UDP. Depending on retry model, the resolver's failing to 95 receive fragmented response may experience long latency or failure 96 due to timeout and reties.And, most of the underlying issues with 97 fragments are unrevealed due to good redundancy and resilience of DNS 98 and dual-stack network. 100 Generally speaking there two approaches for this issue. One is to 101 make the DNS response as small as possible, for example, using ECC 102 instead of RSA to shorten the size of Key and signature. However, 103 few zones are signed by ECC for the time being. In addition there is 104 an uncertainty in the algorithm rollover from RSA to ECC. Another 105 approach is to fall back to TCP by setting on either server side or 106 client side. For resolver it is to set EDNS0 buffsize below a 107 certain number Server. For authoritative servers it is to set their 108 maximum UDP response size small enough. 110 However, one study [Not-speak-TCP] shows that about 17% of resolvers 111 in the samples can not ask a query in TCP when they receive truncated 112 response. It seems a dilemma to choose hurting either the users who 113 can not receive fragments or the users without TCP fallback 114 capacity.There is also some voice of "moving all DNS over TCP". But 115 It is generally desired that DNS can keep the efficiency and high 116 performance by using DNS UDP in most of time and fallback as soon as 117 possible to TCP if necessary for some case. 119 To relieve the problem, this memo introduces an small improvement on 120 DNS responding process by replying an Additional Truncated Response 121 (ATR) just after a normal large response which is to be fragmented. 122 It is a hybrid approach of using UDP when we can, and TCP only when 123 we must. It does not require any changes on resolver and has a 124 deploy-and-gain feature to encourage operators to implement it to 125 benefit their resolvers. 127 [REMOVE BEFORE PUBLICATION] Note that ATR is not just a proposed 128 idea. Some advocates of ATR implemented it based on BIND9 129 (https://gitlab.isc.org/isc-projects/bind9/merge_requests/158). And 130 Some verify it based on an large-scale experiment platform of APNIC 131 lab Section 3 which is introduced in this memo. 133 2. The ATR mechanism 135 The ATR mechanism is very simple that it involves a ATR module in the 136 responding process of current DNS implementation . As show in the 137 following diagram the ATR module is right after truncation loop if 138 the packet is not going to be fragmented. 140 A DNS +-------------+ +-------------+ Normal 141 query | | No | | response 142 +------> Truncation +--------> ATR +---------> 143 | loop | | Module | 144 | truncation? | | truncation? | 145 +-------------+ +-------------+ 146 yes| yes| +-----+ 147 | +-----+timer+--> 148 | +-----+ 149 | Truncated Response 150 +---------------> 151 Truncated Response 153 Figure 1: High-Level Testbed Components 155 The ATR responding process goes as follows: 157 o When an authoritative server receives a query and enters the 158 responding process, it first go through the normal truncation loop 159 to see whether the size of response surpasses the EDNS0 payload 160 size. If yes, it ends up with responding a truncated packets. If 161 no, it enters the ATR module. 163 o In ATR module, similar like truncation loop, the size of response 164 is compared with a value called ATR payload size. If the response 165 of a query is larger than ATR payload size, the server firstly 166 sends the normal response and then coin a truncated response with 167 the same ID of the query. 169 o The server can reply the coined truncated response in no time. 170 But considering the possible impact of network reordering, it is 171 suggested a timer to delay the second truncated response, for 172 example 10~50 millisecond which can be configured by local 173 operation. 175 Note that the choice of ATR payload size and timer SHOULD be 176 configured locally. And the operational consideration and guidance 177 is discussed in Section 4.2 and Section 4.1 respectively. 179 There are three typical cases of ATR-unaware resolver behavior when a 180 resolver send query to an ATR server in which the server will 181 generate a large response with fragments: 183 o Case 1: a resolver (or sub-resolver) will receive both the large 184 response and a very small truncated response in sequence. It will 185 happily accepts the first response and drop the second one because 186 the transaction is over. 188 o Case 2: In case a fragment is dropped in the middle, the resolver 189 will end up with only receiving the small truncated response. It 190 will retry using TCP in no time. 192 o Case 3: For those (probably 30%*17% of them) who can not speak TCP 193 and sitting behind a firewall stubbornly dropping fragments. Just 194 say good luck to them! 196 In the case authoritative server truncated all response surpass 197 certain value , for example setting IPv6-edns-size to 1220 octets, 198 ATR will helpful for resolver with TCP capacity, because the resolver 199 still has a fair chance to receive the large response. 201 3. Experiment on how well ATR works 203 It is worth of mentioning APNIC report[How-ATR-Work] on "How well 204 does ATR actually work?" done by Geoff Huston and Joao Damas after 00 205 version of ATR draft. It was reported firstly in IEPG meeting before 206 IETF 101 and then posted in APNIC Blog later. 208 It is said the test was performed over 55 million endpoints, using an 209 on-line ad distribution network to deliver the test script across the 210 Internet. The result is positive that ATR works! From the end 211 users' perspective, in some 9% of IPv4 cases the use of ATR by the 212 server will improve the speed of resolution of a fragmented UDP 213 response by signaling to the client an immediate switch to TCP to 214 perform a re-query. The IPv6 behavior would improve the resolution 215 times in 15% of cases. 217 It also analyzed the pros and cons of ATR. On one hand, It is said 218 that ATR certainly looks attractive if the objective is to improve 219 the speed of DNS resolution when passing large DNS responses. And 220 ATR is incrementally deployable in favor of decision made by each 221 server operator. On another hand, ATR also has some negative or 222 unanswered factors. One is adding another DNS DDoS attack vector due 223 to the additional packet sent by ATR, (author's note : very small 224 adding actually.) Another issue is risk of RO by the choice of the 225 delay timer which is discussed fully in Section 4.1. It is also 226 founded that the trailing UDP packet may generate ICMP Port 227 Unreachable messages back to the server as a kind of noise (a rate of 228 approximately 1 in 5 responses in our experiments). Note that in 229 author's argument, it is not a big issue and the server can simply 230 ignore it if it decides to adopt ATR. 232 As a conclusion, it is said that "ATR does not completely fix the 233 large response issue. If a resolver cannot receive fragmented UDP 234 responses and cannot use TCP to perform DNS queries, then ATR is not 235 going to help. But where there are issues with IP fragment 236 filtering, ATR can make the inevitable shift of the query to TCP a 237 lot faster than it is today. But it does so at a cost of additional 238 packets and additional DNS functionality". "If a faster DNS service 239 is your highest priority, then ATR is worth considering", said at the 240 end of this report 242 4. Operational considerations 244 There are some operational consideration on ATR, such as the 245 parameter of the ATR timer and ATR payload size, and policies on when 246 ATR is triggered to avoid side-effect. 248 4.1. ATR timer 250 As introduced in Section 2 ATR timer is a way to avoid the impact of 251 network reordering(RO). The value of the timer is critical, because 252 if the delay is too short, the ATR response may be received earlier 253 than the fragmented response (the first piece), the resolver will 254 fall back to TCP bearing the cost which should have been avoided. If 255 the delay is too long, the client may timeout and retry which negates 256 the incremental benefit of ATR. Generally speaking, the delay of the 257 timer should be "long enough, but not too long". 259 To the best knowledge of author, the nature of RO is characterized as 260 follows hopefully helping ATR users understand RO and how to operate 261 ATR appropriately in RO context. 263 o RO is mainly caused by the parallelism in Internet components and 264 links other than network anomaly [Bennett]. It was observed that 265 RO is highly related to the traffic load of Internet components. 266 So RO will long exists as long as the traffic load continue 267 increase and the parallelism is used to enhance network 268 throughput. 270 o The probability of RO varies largely depending on the different 271 tests samples. Some work shown RO probability below 2% [Paxson] 272 [Tinta] and another work was above 90% [Bennett]. But it is 273 agreed that RO is site-dependent and path-dependent. It is 274 observed in that when RO happens, it is mostly exhibited 275 consistently in a small percentages of the paths. It is also 276 observed that higher rates smaller packets were more prone to RO 277 because the sending inter-spacing time was small. 279 o It was reported that the inter-arrival time of RO varies from a 280 few milliseconds to multiple tens of milliseconds [Tinta]. And 281 the larger the packet the larger the inter-arrival time, since 282 larger packets will take longer to be transmitted. 284 Reasonably we can infer that firstly RO should be taken into account 285 because it long exists due to middle Internet components which can 286 not be avoided by end-to-end way. Secondly the mixture of larger and 287 small packets in ATR case will increase the inter-arrival time of RO 288 as well as the its probability. The good news is that the RO is 289 highly site specific and path specific, and persistent which means 290 the ATR operator is able to identify a few sites and paths, setup a 291 tunable timer setting for them, or just put them into a blacklist 292 without replying ATR response. 294 Based on the above analysis it is hard to provide a perfect value of 295 ATR timer for all ATR users due to the diversity of networks. It 296 seems OK to set the timer with a range from ten to hundreds ms, just 297 below the timeout setting of typical resolver. Is suggested that a 298 decision should be made as operator-specific according to the 299 statistic of the RTT of their users. Some measurement shown 300 [Brownlee][Liang] the mean of response time is below 50 ms for the 301 sites with lots of anycast instance like L-root, .com and .net name 302 servers. For that sites, delay less than 50 ms is appropriate. 304 4.2. ATR payload size 306 Regarding the operational choice for ATR payload size, there are some 307 good input from APNIC study [scoring-dns-root]on how to react to 308 large DNS payload for authoritative server. The difference in ATR is 309 that ATR focuses on the second response after the ordinary response. 311 For IPv4 DNS server, it is suggested the study that do not truncate 312 and fragment IPv4 UDP response with a payload up to 1472 octets which 313 is Ethernet MTU(1500) minus the sum of IPv4 header(20) and UDP 314 header(8). The reason is to avoid gratuitously fragmenting outbound 315 packets and TCP fallback at the source. 317 In the case of ATR, the first ordinary response is emitted without 318 knowing it be to fragmented or not on the path. If a large value is 319 set up to 1472 octets, payload size between 512 octets and the large 320 value size will probably get fragmented by aggressive firewalls which 321 leads losing the benefit of ATR. If ATR payload size set exactly 512 322 octets, in most of case ATR response and the single unfragmented 323 packets are under a race at the risk of RO. 325 Given IPv4 fragmentation issue is not so serious compared to IPv6, it 326 is suggested in this memo to set ATR payload size 1472 octets which 327 means ATR only fit large DNS response larger than 1500 octets in 328 IPv4. 330 For IPv6 DNS server, similar to IPv4, the APNIC study is suggested 331 that do not truncate IPv6 UDP packets with a payload up to 1,452 332 octets which is Ethernet MTU(1500) minus the sum of IPv6 header(40) 333 and UDP header(8). 1452 octets is chosen to avoid TCP fallback in the 334 context that most TCP MSS in the root server is not set probably at 335 that time. 337 In the case of ATR considering the second truncated response, a 338 smaller size: 1232 octets, which is IPv6 MTU for most network 339 devices(1280) minus the sum of IPv6 header(40) and UDP header(8), 340 should be chosen as ATR payload size to trigger necessary TCP 341 fallback. As a complementary requirement with ATR, the TCP MSS 342 should be set 1220 octets to avoid Packet Too Big ICMP message as 343 suggested in the APNIC study. 345 In short, it is recommended that in IPv4 ATR payload size SHOULD be 346 1472 octets, and in IPv6 the value SHOULD be 1232 octets. 348 4.3. Less aggressiveness of ATR 350 There is a concern ATR sends TC=1 response too aggressively 351 especially in the beginning of adoption. ATR can be implemented as 352 an optional and configurable feature at the disposal of authoritative 353 server operator. One of the idea to mitigate this aggressiveness, 354 ATR may respond TC=1 responses at a low possibility, such as 10%. 356 Another way is to reply ATR response selectively. It is observed 357 that RO and IPv6 fragmentation issues are path specific and 358 persistent due to the Internet components and middle box. So it is 359 reasonable to keep a ATR "whitelist" by counting the retries and 360 recording the IP destination address of that large response causing 361 many retires. ATR only acts to those queries from the IP address in 362 the white list. 364 5. Security Considerations 366 There may be concerns on DDoS attack problem due to the fact that the 367 ATR introduces multiple responses from authoritative server. The 368 extra packet is pretty small. In the worst case, it's 50% more 369 packets and they are small 371 DNS cookies [RFC7873] and RRL on authoritative may be possible 372 solutions 374 6. IANA considerations 376 No IANA considerations for this memo 378 7. Acknowledgments 380 Many thanks to reviewers and their comments. Geoff Huston and Joao 381 Damas did a testing on the question "How well does ATR actually 382 work?". Alexander Dupuy proposed the idea to distinguish ATR 383 responses from normal ones. Akira Kato contributed ideas on 384 operational consideration. Shane Kerr help author with the security 385 consideration. Stephane Bortzmeyer gave thought of happyeyeballs on 386 resolver side. 388 Acknowledgments are also give to Mukund Sivaraman, Evan Hunt and Mark 389 Andrews who implement it and maintained it in a brunch in BIND9 code 390 base. 392 8. References 394 [ATR-Github] 395 "XML source file and test script of DNS ATR", September 396 2017, . 398 [Bennett] Bennett, J. C. R., "Packet Reordering is Not Pathological 399 Network Behavior", December 1999, 400 . 403 [Brownlee] 404 Brownlee, N., "Response time distributions for global name 405 servers", 2002, 406 . 409 [DNSSEC-impact] 410 Broek, G. V. D., "DNSSEC meets real world: dealing with 411 unreachability caused by fragmentation", April 2014, 412 . 415 [How-ATR-Work] 416 Huston, G., "How well does ATR actually work?", April 417 2018, . 420 [I-D.taylor-v6ops-fragdrop] 421 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 422 M., and T. Taylor, "Why Operators Filter Fragments and 423 What It Implies", draft-taylor-v6ops-fragdrop-02 (work in 424 progress), December 2013. 426 [IPv6-frag-DNS] 427 Huston, G., "Dealing with IPv6 fragmentation in the DNS", 428 August 2017, . 431 [Liang] Liang, J., "Measuring Query Latency of Top Level DNS 432 Servers", February 2013, 433 . 436 [Not-speak-TCP] 437 Huston, G., "A Question of DNS Protocols", August 2013, 438 . 441 [Paxson] Paxson, V., "End-to-End Internet Packet Dynamics", August 442 1999, . 445 [RFC1035] Mockapetris, P., "Domain names - implementation and 446 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 447 November 1987, . 449 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 450 for DNS (EDNS(0))", STD 75, RFC 6891, 451 DOI 10.17487/RFC6891, April 2013, 452 . 454 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 455 "Observations on the Dropping of Packets with IPv6 456 Extension Headers in the Real World", RFC 7872, 457 DOI 10.17487/RFC7872, June 2016, 458 . 460 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 461 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 462 . 464 [scoring-dns-root] 465 Huston, G., "Scoring the DNS Root Server System", November 466 2016, . 469 [Tinta] Tinta, S. P., "Characterizing End-to-End Packet Reordering 470 with UDP Traffic", August 2009, . 474 Appendix A. Considerations on Resolver awareness of ATR 476 ATR proposed in this memo is a server-side function which requires no 477 change in resolver, so it is not required that resolver MUST 478 recognized ATR and react accordingly. But it may helpful for some 479 cases where a resolver is able to recognized ATR response, for 480 example by checking the large edns0 payload size and TrunCation bit. 482 One case is use ATR is used as troubleshooting tool by which resolver 483 operators are able to flag problematic name servers. The resolver 484 operators is enable to log cases where ATR responses is received 485 without a (reassembled) UDP response to a query. In the case of 486 receiving a ATR, RDNS can choose to restrict maximum EDNS to a lower 487 value than the default 4096 that currently used. 489 Another case is that when receiving a ATR response a ATR-aware 490 resolver can adopt a "happyeyeballs" strategy by opening a separate 491 transaction sending the query via TCP instead of falling back to TCP 492 and closing the original UDP transaction. Listen to port 53 on both 493 TCP and UDP port 53 will enhance the availability and reduce the 494 latency. It will add more tolerance to network reordering issue as 495 well. However, it should be taken into account about the balance of 496 resolver's resource. Less priority should be given to that function 497 when the resolver is "busy". 499 The awareness of ATR on resolver can also avoid sending ICMP Port 500 Unreachable messages back to the server. In some implementations, 501 reusing the same UDP sockets for multiple queries will not generating 502 that ICMP noise. 504 However resolver use case of ATR is currently outside of the scope of 505 server-ATR proposal. It needs further discussion. 507 Appendix B. Revision history of this document 509 B.1. draft-song-atr-large-resp-01 511 After receiving reviews and comments, changes of 01 version are shown 512 as belows: 514 o Rewrite introduction and add another goal of ATR as a measuring 515 tool; 517 o Add section 3 indicating a ATR response. An bit in the EDNS0 OPT 518 header is defined as a indicator of ATR response. The flag bit is 519 called "ATR Response" (AT) bit; 521 o Add Section 4 Operation considerations, which discuss ATR timer , 522 ATR payload size, and less aggressiveness of ATR; 524 o Add IANA consideration to register the AT bit; 526 o Add section 7 Acknowledgments; 528 o Append a list of references regarding Network reordering, and 529 APNIC's study on IPv6 and DNS; 531 o Add Appendix A, An introduce of APNIC testing work and author's 532 comments; 534 o Appendix B. Considerations on Resolver awareness of ATR; 536 o Change the category="std" . It is said in RFC6891 IETF Standards 537 Action is required for assignments of new EDNS(0) flags. So the 538 draft should be categorized as standard track if registering AT 539 bit is desired in this document. 541 Change history is also available in the public GitHub repository 542 where this document is maintained: . 545 B.2. draft-song-atr-large-resp-02 547 Changes in 02 version of ATR draft: 549 o Remove the section of introduction of AT bit as well as 550 requirement of IANA registration of that bit; 552 o Change the category of this document to experimental and move the 553 introduction of APNIC's experiment from Appendix A to section 3; 555 o Add more names in Acknowledgments part after IETF102; 557 B.3. draft-song-atr-large-resp-03 559 Changes in 03 version of ATR draft: 561 o Add related work in the introduction session; 563 o Introduce ICMP noise as a finding of APNIC's experiment and 564 propose how to avoid it in Appendix A; 566 o Change the category from "exp" to "info"; 568 o Move to ISE for review. 570 o Add one author S. Wang 572 Authors' Addresses 574 Linjian Song 575 Beijing Internet Institute 576 2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA 577 Beijing 100176 578 P. R. China 580 Email: songlinjian@gmail.com 581 URI: http://www.biigroup.com/ 583 Shengling Wang 584 Beijing Normal University 585 Beijing Normal University, No. 19, XinJieKouWai St., HaiDian District 586 Beijing 100875 587 P. R. China 589 Email: wangshengling@bnu.edu.cn 590 URI: https://cist.bnu.edu.cn/