Re: China’s Slow Transnational Network

Mon Mar 2 22:47:58 UTC 2020

>
> You seem to be implying that you don't believe/can't see the GFW

No, that's not what I meant. I thought mandatory content filtering at the
border means traffic throttling at the border, deliberately or accidentally
rate-limiting the traffic, now
I think he was referring to GFW and the side effect of deep packet
inspection.

In fact, 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.

Best,
Pengxiong Zhu
Department of Computer Science and Engineering
University of California, Riverside

On Mon, Mar 2, 2020 at 1:13 PM Matt Corallo <nanog at as397444.net> wrote:

> > find out direct evidence of mandatory content filtering at the border
>
> You seem to be implying that you don't believe/can't see the GFW, which
> seems surprising. I've personally had issues with traffic crossing it
> getting RST'd (luckily I was fortunate enough to cross through a GFW
> instance which was easy to avoid with a simple iptables DROP), but its
> also one of the most well-studied bits of opaque internet censorship
> gear in the world. I'm not sure how you could possibly miss it.
>
> Matt
>
> On 3/2/20 2:55 PM, Pengxiong Zhu wrote:
> > Yes, we agree. The poor transnational Internet performance effectively
> > puts any foreign business that does not have a physical presence (i.e.,
> > servers) in China at a disadvantage.
> > The challenge is to find out direct evidence to prove mandatory content
> > filtering at the border, if the government is actually doing it.
> >
> > Best,
> > Pengxiong Zhu
> > Department of Computer Science and Engineering
> > University of California, Riverside
> >
> >
> > On Mon, Mar 2, 2020 at 8:38 AM Matt Corallo <nanog at as397444.net
> > <mailto:nanog at as397444.net>> wrote:
> >
> >     It also gives local competitors a leg up by helping domestic apps
> >     perform better simply by being hosted domestically (or making
> >     foreign players host inside China).
> >
> >>     On Mar 2, 2020, at 11:27, Ben Cannon <ben at 6by7.net
> >>     <mailto:ben at 6by7.net>> wrote:
> >>
> >>     
> >>     It’s the Government doing mandatory content filtering at the
> >>     border.  Their hardware is either deliberately or accidentally
> >>     poor-performing.
> >>
> >>     I believe providing limited and throttled external connectivity
> >>     may be deliberate; think of how that curtails for one thing;
> >>     streaming video?
> >>
> >>     -Ben.
> >>
> >>     -Ben Cannon
> >>     CEO 6x7 Networks & 6x7 Telecom, LLC
> >>     ben at 6by7.net <mailto:ben at 6by7.net>
> >>
> >>
> >>
> >>>     On Mar 1, 2020, at 9:00 PM, Pengxiong Zhu <pzhu011 at ucr.edu
> >>>     <mailto:pzhu011 at ucr.edu>> wrote:
> >>>
> >>>     Hi all,
> >>>
> >>>     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
> >>>     interesting findings.
> >>>
> >>>     We find China's transnational networks have extremely poor
> >>>     performance when accessing foreign sites, where the throughput is
> >>>     often persistently
> >>>     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).
> >>>
> >>>     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.
> >>>
> >>>
> >>>     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.
> >>>
> >>>     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.
> >>>     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.
> >>>
> >>>     Here is the link to our paper:
> >>>     https://www.cs.ucr.edu/~zhiyunq/pub/sigmetrics20_slowdown.pdf
> >>>
> >>>     We appreciate any comments or feedback.
> >>>     --
> >>>
> >>>     Best,
> >>>     Pengxiong Zhu
> >>>     Department of Computer Science and Engineering
> >>>     University of California, Riverside
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200302/bf382b28/attachment.html>