<div dir="ltr"><div dir="ltr">In fact, the three large carriers provide 98.5% of China’s total transnational bandwidth. We observe this across all the three large carriers, as well as one smaller carrier, CERNET(China Education and Research Network). <br clear="all"><div><div dir="ltr" class="gmail_signature"><br>Best,<br>Pengxiong Zhu<br>Department of Computer Science and Engineering<br>University of California, Riverside</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 2, 2020 at 12:12 PM Ben Cannon <<a href="mailto:ben@6by7.net">ben@6by7.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><blockquote type="cite"><div>On Mar 2, 2020, at 11:38 AM, Pengxiong Zhu <<a href="mailto:pzhu011@ucr.edu" target="_blank">pzhu011@ucr.edu</a>> wrote:</div><br><div><div dir="ltr">Those are good insights. Our first guess is censorship too, and we discussed the possibilities of censorship side effects in Section 5.1 <i>Censorship</i>.<div><br><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It’s the Government doing mandatory content filtering at the border.  Their hardware is either deliberately or accidentally poor-performing. <br></blockquote><div><div dir="ltr"><br></div><div dir="ltr">However, GFW operates as an on-path system [72], which only processes copies of existing packets without the ability to discard existing packets. Evidently, prior work has shown that GFW fails to inject RST packets during busy hours while the packets containing sensitive keywords are still delivered successfully [34]. However, we are unable to rule out the possibility that GFW has evolved to acquire the capability to discard packets.<br></div><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Maybe... I dunno.... get rid of the Great Firewall of China?</blockquote><div><br></div><div>We designed a small experiment to locate the hops with GFW presence, and then try to match them with the bottleneck hops. We found only in 34.45% of the cases, the GFW hops match the bottleneck hops. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My guess is that it’s all the DDoS traffic coming from China saturating the links. <br></blockquote><div><br></div><div>In fact, Great Canon (GC) [55] is such an in-path system. But it is known for intercepting a subset of traffic (based on protocol type) only. What’s more, GC has been activated only twice in history (the last one in 2015 [55]). However, it might be the case that the in-path capability is re-purposed to perform general traffic throttling. If that is the case, they have done a good job because the throttling resembles natural congestion from the loss rate and latency point of view. </div></div></div></div></div></div></blockquote><div><br></div><div>I believe this is what’s happening, and I believe they are rate-limiting and causing actual congestion, as opposed to simulating it. The losses would be real, actual saturation, on simply rate-limited flows.  Unclear if this is being done on a per-flow basis or per-source or what.  You might be able to find out.  I’m curious if you see this across all carriers or only the larger ones?   </div><div><br></div><div>-Ben.</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div><div><div><div>The asymmetric performance between downstream and upstream traffic can be explained by the natural imbalance of transnational traffic (where the upstream traffic from China to outside is not significant enough to throttle).<br></div><div> </div><div dir="ltr"><br>Best,<br>Pengxiong Zhu<br>Department of Computer Science and Engineering<br>University of California, Riverside</div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 2, 2020 at 8:11 AM Compton, Rich A <<a href="mailto:Rich.Compton@charter.com" target="_blank">Rich.Compton@charter.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div><p class="MsoNormal"><span style="font-size:12pt">My guess is that it’s all the DDoS traffic coming from China saturating the links. 
<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:12pt"><u></u> <u></u></span></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in"><p class="MsoNormal"><b><span style="font-size:12pt">From: </span></b><span style="font-size:12pt">NANOG Email List <<a href="mailto:nanog-bounces@nanog.org" target="_blank">nanog-bounces@nanog.org</a>> on behalf of Pengxiong Zhu <<a href="mailto:pzhu011@ucr.edu" target="_blank">pzhu011@ucr.edu</a>><br>
<b>Date: </b>Monday, March 2, 2020 at 8:58 AM<br>
<b>To: </b>NANOG list <<a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a>><br>
<b>Cc: </b>Zhiyun Qian <<a href="mailto:zhiyunq@cs.ucr.edu" target="_blank">zhiyunq@cs.ucr.edu</a>><br>
<b>Subject: </b>China’s Slow Transnational Network<u></u><u></u></span></p>
</div>
<div><p class="MsoNormal"><u></u> <u></u></p>
</div>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)">Hi all,<u></u><u></u></span></p>
</div><p class="MsoNormal"><u></u> <u></u></p>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)">We are a group of researchers at University of California, Riverside who have been working on measuring the transnational network performance (and have previously asked questions on the mailing list). Our work
 has now led to a publication in Sigmetrics 2020 and we are eager to share some<u></u><u></u></span></p>
</div>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)">interesting findings. <u></u><u></u></span></p>
</div><p class="MsoNormal"><u></u> <u></u></p>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)">We find China's transnational networks have extremely poor performance when accessing foreign sites, where the throughput is often persistently<u></u><u></u></span></p>
</div>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)">low (e.g., for the majority of the daytime). Compared to other countries we measured including both developed and developing, China's transnational network performance is among the worst (comparable and even
 worse than some African countries).<u></u><u></u></span></p>
</div><p class="MsoNormal"><u></u> <u></u></p>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)">Measuring from more than 400 pairs of mainland China and foreign nodes over more than 53 days, our result shows when data transferring from foreign nodes to China, 79% of measured connections has throughput lower
 than the 1Mbps, sometimes it is even much lower. The slow speed occurs only during certain times and forms a diurnal pattern that resembles congestion (irrespective of network protocol and content), please see the following figure. The diurnal pattern is fairly
 stable, 80% to 95% of the transnational connections have a less than 3 hours standard deviation of the slowdown hours each day over the entire duration. However, the speed rises up from 1Mbps to 4Mbps in about half an hour.<u></u><u></u></span></p>
</div><p class="MsoNormal"><u></u> <u></u></p>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)"><img id="gmail-m_1703693448744699997gmail-m_-1187586984361025445_x0000_i1025" alt="blob:null/71cf5a6a-3841-41ce-a1d4-207b59182189"><u></u><u></u></span></p>
</div><p class="MsoNormal"><u></u> <u></u></p>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)">We are able to confirm that high packet loss rates and delays are incurred in the foreign-to-China direction only. Moreover, the end-to-end loss rate could rise up to 40% during the slow period, with ~15% on
 average.<u></u><u></u></span></p>
</div>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)"><u></u> <u></u></span></p>
</div>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)">There are a few things noteworthy regarding the phenomenon. First of all, all traffic types are treated equally, HTTP(S), VPN, etc., which means it is discriminating or differentiating any specific kinds of traffic.
 Second, we found for 71% of connections, the bottleneck is located inside China (the second hop after entering China or further), which means that it is mostly unrelated to the transnational link itself (e.g., submarine cable). Yet we never observed any such
 domestic traffic slowdowns within China.<u></u><u></u></span></p>
</div>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)">Assuming this is due to congestion, it is unclear why the infrastructures within China that handles transnational traffic is not even capable to handle the capacity of transnational links, e.g., submarine cable,
 which maybe the most expensive investment themselves.<u></u><u></u></span></p>
</div><p class="MsoNormal"><u></u> <u></u></p>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)">Here is the link to our paper:<u></u><u></u></span></p>
</div><p class="MsoNormal"><a href="https://www.cs.ucr.edu/~zhiyunq/pub/sigmetrics20_slowdown.pdf" target="_blank">https://www.cs.ucr.edu/~zhiyunq/pub/sigmetrics20_slowdown.pdf</a><span style="color:rgb(49,49,49)"><br>
<br style="word-spacing:1px">
<br>
<u></u><u></u></span></p>
<div><p class="MsoNormal"><span style="color:rgb(49,49,49)">We appreciate any comments or feedback. <u></u><u></u></span></p>
</div><p class="MsoNormal">-- <u></u><u></u></p>
<div><p class="MsoNormal"><br>
Best,<br>
Pengxiong Zhu<br>
Department of Computer Science and Engineering<br>
University of California, Riverside<u></u><u></u></p>
</div>
</div>
The contents of this e-mail message and <br>any attachments are intended solely for the <br>addressee(s) and may contain confidential <br>and/or legally privileged information. If you<br>are not the intended recipient of this message<br>or if this message has been addressed to you <br>in error, please immediately alert the sender<br>by reply e-mail and then delete this message <br>and any attachments. If you are not the <br>intended recipient, you are notified that <br>any use, dissemination, distribution, copying,<br>or storage of this message or any attachment <br>is strictly prohibited.</div>

</blockquote></div>
</div></blockquote></div><br></div></blockquote></div>