Re: Long hops on international paths
Hi Paul, Just curious. How do you determine they are the same routers? Is it based on IP address or MAC addresses? Or using CAIDA’s router alias database? Also how do you draw the conclusion that the AS1299 router is indeed in Chicago? IP-geolocation based on rDNS is not always accurate though. Pengxiong On Mon, Jan 17, 2022 at 10:03 AM PAUL R BARFORD wrote: > Hello, > > I am a researcher at the University of Wisconsin. My colleagues at > Northwestern University and I are studying international Internet > connectivity and would appreciate your perspective on a recent finding. > > We're using traceroute data from CAIDA's Ark project for our work. We've > observed > that many international links (i.e., a single hop on an end-to-end path > that connects two countries where end points on the hop are identified via > rDNS) tend to originate/terminate at the same routers. Said another way, > we are observing a relatively small set of routers in different countries > tend to have a majority of the international connections - this is > especially the case for hops that terminate in the US. For example, > there is a router operated by Telia (AS1299) in Chicago that has a high > concentration of such links. We were a bit surprised by this finding since > even though it makes sense that the set of providers is relatively small > (i.e., those that offer global connectivity), we assumed that the set of > routers that used for international connectivity within any one country > would tend to be more widely distributed (at least with respect to how they > appear in traceroute data - MPLS notwithstanding). > > We're interested in whether or not this is indeed standard practice and if > so, the cost/benefit for configuring international connectivity in this > way? > > Any thoughts or insights you might have would be greatly appreciated - > off-list responses are welcome. > > Thank you. > > Regards, PB > > Paul Barford > University of Wisconsin - Madison > > -- Regards, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside
Re: Amateur Hour - NANOG79 Video Archives?
Got it, thanks! Pengxiong On Sun, Jun 14, 2020 at 2:07 PM Tom Beecher wrote: > That is the correct Youtube channel, yes. > > Monday is 2 weeks from the conference start, so I think we can safely say > give it a couple more days. Edward is really good about following up on > these things, and we know that the vendor that we worked with is really > really busy with a lot of virtual conferences these days. > > On Sun, Jun 14, 2020 at 3:10 PM Pengxiong Zhu wrote: > >> Hi Mick and Illisa, >> >> Is this <https://www.youtube.com/channel/UCIvcN8QNgRGNW9osYLGsjQQ> the >> NANOG Youtube channel? I didn't find the NANOG79 videos, did you? >> >> Regards, >> Pengxiong Zhu >> Department of Computer Science and Engineering >> University of California, Riverside >> >> >> On Thu, Jun 4, 2020 at 6:03 AM Mick O'Donovan wrote: >> >>> On Thu, Jun 04, 2020 at 08:36:59AM -0400, Ilissa Miller wrote: >>> > Hi Mick - just chiming in. Edward mentioned they should be live >>> within 2 >>> > weeks on the NANOG YouTube channel in the closing remarks. >>> > >>> > :) >>> >>> Missed that sorry - as you were all :) >>> >>> -- >>> - MickoD >>> >> -- Regards, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside
Re: Amateur Hour - NANOG79 Video Archives?
Hi Mick and Illisa, Is this <https://www.youtube.com/channel/UCIvcN8QNgRGNW9osYLGsjQQ> the NANOG Youtube channel? I didn't find the NANOG79 videos, did you? Regards, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Thu, Jun 4, 2020 at 6:03 AM Mick O'Donovan wrote: > On Thu, Jun 04, 2020 at 08:36:59AM -0400, Ilissa Miller wrote: > > Hi Mick - just chiming in. Edward mentioned they should be live within 2 > > weeks on the NANOG YouTube channel in the closing remarks. > > > > :) > > Missed that sorry - as you were all :) > > -- > - MickoD >
Re: The Cost of Paid Peering with Chinese ISPs
Thank you for your understanding and your patience and kindness to explain it to us. We really appreciate it. We will keep that in mind and won’t ask this kind of questions again. Thanks again. Pengxiong On Wed, Apr 1, 2020 at 1:59 PM Tom Beecher wrote: > I do understand that you mean well, but do realize that interconnection > between the rest of the world and the networks controlled by the Chinese > government is a very, very sensitive and often touchy subject. It's also > generally true that networks aren't going to disclose terms of commercial > relationships on a public mailing list. ( By and large those terms aren't > likely to be disclosed privately either. :) ) > > On Wed, Apr 1, 2020 at 3:28 PM Pengxiong Zhu wrote: > >> Hi folks, >> >> We got plenty of positive responses in our last email regarding China's >> slow transnational network. Many are suggesting it is likely influenced by >> commercial decisions instead of censorship. It seems like the three Chinese >> ISPs don't really have enough peering internationally in Asia, and they >> have very strong bargaining power when it comes to peering. >> >> Some suggest the cost of moving data to China is way lower if an ISP >> peers with US/European ISPs than directly with the Chinese ISPs. We assume >> the reason why those US/European ISPs offer cheaper prices is that they >> have settlement-free peering with Chinese ISPs. However, the "free-tier" >> capacity is simply not enough to handle the demand -- the US/European ISPs >> now have way more traffic going into China, thus saturating the link and >> causing congestion. >> >> So we are wondering, do the Tier-1 US/European ISPs really have >> settlement-free peering with Chinese ISPs? If we want to do paid peering >> directly with the Chinese ISPs or purchase the full/partial transit, what >> is the price range? >> >> From the BGP information, we know some of the peers of AS4134 (the >> biggest one) are: >> - Telia Carrier(AS1299) >> - Cogent Communications(AS174) >> - NTT Communications (America)(AS2914) >> - Level3(AS3356) >> - Tata Communications(America) Inc (AS6453) >> - Verizon Business/UUnet(AS701) >> - Zayo Bandwidth(AS6461) >> - AT Services, Inc.(AS7018) >> - GTT Communications Inc.(AS3257) >> - Comcast Cable Communications, LLC(AS7922) >> >> It would be much appreciated if the operators of any such networks can >> give chime in. Thanks! >> >> Regards, >> Pengxiong Zhu >> Department of Computer Science and Engineering >> University of California, Riverside >> > -- Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside
Re: The Cost of Paid Peering with Chinese ISPs
> > No one suggested it isn’t censorship, > In fact, some replies suggested it’s more commercial actions. We said it's "likely influenced by commercial decisions", we didn't say censorship is out of the question. We still think censorship is the possible cause, but we run out of methods to verify it, that's why we switched to commercial actions to try our luck. If commercial actions don't seem to cause the slowdown, then it would be definitely censorship. Most of the performance hit is because of commercial actions, not > censorship. > When there is a tri-opoly, with no opportunity of competition, its easily > possible to set prices which are very different than market conditions. > This is what is happening here. > Prices are set artificially high, so their interconnection partners wont > purchase enough capacity. additionally, the three don't purchase enough to > cover demand for their own network. Results in congestion. > >-- > comment what also doesn't help is that the Chinese carriers don't want to peer in > Asia, not even with globally transit-free tier-1 networks. Their closest > point of interconnection is typically in Europe or the US, so thousands of > miles away from the end user. >-- > Anonymous comment > you’re bating here. > Once again we are confused by the accusation. We don't want to bait anyone for anything. Not deploying enough international capacity is absolutely a form or > censorship deployed to great avail > Yes we agree it is also a form of censorship. However, it is based on the assumption that China didn't deploy enough international capacity, which we don't have direct proof of it. On the contrary, from the stable performance of the traffic going out of China, it is very likely the assumption is not true. They might have enough physical capacity, but they don't make good use of it.
Re: The Cost of Paid Peering with Chinese ISPs
Sorry we didn’t know this is out of scope. What do you mean by baiting questions? We are not very familiar with the peer protocol, so we don’t know what questions can be discussed here or not. We are researches, we just want to dig more to the cause of the slowdown that we observed. And we thought those questions are okay to ask here, which are not. But we don’t want bait anyone. Sorry about the lack of knowledge of what can be discussed here. Pengxiong On Wed, Apr 1, 2020 at 12:34 PM Ca By wrote: > This topic is out of scope for the list. Please stop emailing these > baiting questions. > > On Wed, Apr 1, 2020 at 12:27 PM Pengxiong Zhu wrote: > >> Hi folks, >> >> We got plenty of positive responses in our last email regarding China's >> slow transnational network. Many are suggesting it is likely influenced by >> commercial decisions instead of censorship. It seems like the three Chinese >> ISPs don't really have enough peering internationally in Asia, and they >> have very strong bargaining power when it comes to peering. >> >> Some suggest the cost of moving data to China is way lower if an ISP >> peers with US/European ISPs than directly with the Chinese ISPs. We assume >> the reason why those US/European ISPs offer cheaper prices is that they >> have settlement-free peering with Chinese ISPs. However, the "free-tier" >> capacity is simply not enough to handle the demand -- the US/European ISPs >> now have way more traffic going into China, thus saturating the link and >> causing congestion. >> >> So we are wondering, do the Tier-1 US/European ISPs really have >> settlement-free peering with Chinese ISPs? If we want to do paid peering >> directly with the Chinese ISPs or purchase the full/partial transit, what >> is the price range? >> >> From the BGP information, we know some of the peers of AS4134 (the >> biggest one) are: >> - Telia Carrier(AS1299) >> - Cogent Communications(AS174) >> - NTT Communications (America)(AS2914) >> - Level3(AS3356) >> - Tata Communications(America) Inc (AS6453) >> - Verizon Business/UUnet(AS701) >> - Zayo Bandwidth(AS6461) >> - AT Services, Inc.(AS7018) >> - GTT Communications Inc.(AS3257) >> - Comcast Cable Communications, LLC(AS7922) >> >> It would be much appreciated if the operators of any such networks can >> give chime in. Thanks! >> >> Regards, >> Pengxiong Zhu >> Department of Computer Science and Engineering >> University of California, Riverside >> > -- Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside
The Cost of Paid Peering with Chinese ISPs
Hi folks, We got plenty of positive responses in our last email regarding China's slow transnational network. Many are suggesting it is likely influenced by commercial decisions instead of censorship. It seems like the three Chinese ISPs don't really have enough peering internationally in Asia, and they have very strong bargaining power when it comes to peering. Some suggest the cost of moving data to China is way lower if an ISP peers with US/European ISPs than directly with the Chinese ISPs. We assume the reason why those US/European ISPs offer cheaper prices is that they have settlement-free peering with Chinese ISPs. However, the "free-tier" capacity is simply not enough to handle the demand -- the US/European ISPs now have way more traffic going into China, thus saturating the link and causing congestion. So we are wondering, do the Tier-1 US/European ISPs really have settlement-free peering with Chinese ISPs? If we want to do paid peering directly with the Chinese ISPs or purchase the full/partial transit, what is the price range? >From the BGP information, we know some of the peers of AS4134 (the biggest one) are: - Telia Carrier(AS1299) - Cogent Communications(AS174) - NTT Communications (America)(AS2914) - Level3(AS3356) - Tata Communications(America) Inc (AS6453) - Verizon Business/UUnet(AS701) - Zayo Bandwidth(AS6461) - AT Services, Inc.(AS7018) - GTT Communications Inc.(AS3257) - Comcast Cable Communications, LLC(AS7922) It would be much appreciated if the operators of any such networks can give chime in. Thanks! Regards, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside
Re: China’s Slow Transnational Network
Thank you for your insights. We are not so familiar with interconnect and peering, we will ask you some questions for clarification first. Hope you don't mind. :-) When there is a tri-opoly, with no opportunity of competition, its easily > possible to set prices which are very different than market conditions. I assume the tri-opoly involves a Chinese ISP, outside ISP A, outside ISP B. Who is competing with whom? Why its easily possible to set prices which are very different than market conditions? > additionally, the three don't purchase enough to cover demand for their > own network. > Do you mean that the three don't purchase enough capacity for their traffic going out of their network(China->Outside)? If this is what you mean, however, we don't observe low speed in that direction. We assume there is not so much traffic going out of China, comparing to the traffic coming in. Also, why would the three purchase outbound traffic if they set their inbound traffic artificially high? They could charge some peers less for the outbound traffic to solve the problem. Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Mon, Mar 2, 2020 at 2:58 PM Tom Paseka wrote: > Most of the performance hit is because of commercial actions, not > censorship. > > When there is a tri-opoly, with no opportunity of competition, its easily > possible to set prices which are very different than market conditions. > This is what is happening here. > > Prices are set artificially high, so their interconnection partners wont > purchase enough capacity. additionally, the three don't purchase enough to > cover demand for their own network. Results in congestion. > > On Mon, Mar 2, 2020 at 2:49 PM Pengxiong Zhu wrote: > >> 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 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 >> > <mailto:na...@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 >> >> <mailto:b...@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
Re: China’s Slow Transnational Network
I see. Thank you! Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Sat, Mar 21, 2020 at 9:13 AM Mark Tinka wrote: > > > On 21/Mar/20 09:09, Pengxiong Zhu wrote: > > How do they deliberately congest peering ports? Do you hear from those > Chinese operators or you observe this from the traffic? > > > Simple - let them run at 350% of capacity and pipeline upgrades for Lord > knows how long :-). > > On a serious note, let's have a beer. > > > Seems like you also think GFW is part of the cause, > > > I do - each of my trips to China have questioned the role of my VPN for my > online experience. > > > however, we don't have direct evidence. > > > I won't argue with you there, you did the groundwork. I'm just being > anecdotal. > > > Just curious, What is your "problems"? I thought it's congestion. > > > Accessibility and penetration rates. > > Mark. >
Re: China’s Slow Transnational Network
> > I know about Chinese operators who will deliberately congest peering ports > to influence 3rd party network behaviour. How do they deliberately congest peering ports? Do you hear from those Chinese operators or you observe this from the traffic? Most countries in Africa do not implement great big firewalls. Our problems > are quite different :-\... Not having great big firewalls tends to help :-). > Seems like you also think GFW is part of the cause, however, we don't have direct evidence. Just curious, What is your "problems"? I thought it's congestion. Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Sun, Mar 15, 2020 at 11:13 PM Mark Tinka wrote: > > > On 15/Mar/20 22:51, Frank Habicht wrote: > > > > > thanks for the "quotes", Mark. I agree. > > > > > https://www.caida.org/publications/presentations/2018/investigating_causes_congestion_african_afrinic/investigating_causes_congestion_african_afrinic.pdf > > > > page 23: > > Results Overview > > • No evidence of widespread congestion > >- 2.2% of discovered link showed evidence of congestion at the end of > > our measurements campaign > > > > page 34: > > Conclusions > > • Measured IXPs were congestion-free, which promotes peering in the > > region > > > > https://conferences.sigcomm.org/imc/2017/papers/imc17-final182.pdf > > > > my conclusion: s/congestion/congestion or the lack thereof/g > > > > Frank Habicht > > > > PS: yes, i could name peers that once had inadequate links into an IXP. > > but for how long did that happen? (yes..., any minute is too long...) > > Indeed. > > There was a time when backhaul links between ISP routers at the exchange > point and their nearest PoP were based on E1's, wireless, e.t.c. But > that could be said of, pretty much, every exchange point that kicked off > inside of the last 2.5 decades. > > Nowadays, such links, if they exist, are the very deep exception, not > the rule. > > Mark. >
Re: China’s Slow Transnational Network
> > Most countries in Africa do not implement great big firewalls. Our > problems are quite different :-\... > I know Caida has one paper on the congestion on Africa's IXPs substrate. However, we did find Kenya, Nigeria and South Africa have better transnational performance than China, while the performance of Ghana and Egypt was worse than China, at least that's what we saw from the web4africa VPSes we brought. We've seen somewhat similar behaviour from these networks when peering > outside of China > Sorry I am a bit confused here. What do you mean by "these networks"? When you say "peering outside of China", who is peering who exactly? Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Tue, Mar 3, 2020 at 12:17 AM Mark Tinka wrote: > > > On 3/Mar/20 00:57, Tom Paseka via NANOG wrote: > > > > > Prices are set artificially high, so their interconnection partners > > wont purchase enough capacity. additionally, the three don't > > purchase enough to cover demand for their own network. Results in > > congestion. > > We've seen somewhat similar behaviour from these networks when peering > outside of China, perhaps, to influence the flow of money and traffic. > > We have zero patience for such things. > > Mark. >
Re: China’s Slow Transnational Network
DDoS traffic is coming from China to the outside world, which should saturate the upstream link of China, however, what we observed is that the upstream link has high and stable performance, while the downstream link of China, which is traffic coming from the outside world to China, is suffering from slow speed. Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Mon, Mar 2, 2020 at 8:11 AM Compton, Rich A wrote: > My guess is that it’s all the DDoS traffic coming from China saturating > the links. > > > > *From: *NANOG Email List on behalf of Pengxiong > Zhu > *Date: *Monday, March 2, 2020 at 8:58 AM > *To: *NANOG list > *Cc: *Zhiyun Qian > *Subject: *China’s Slow Transnational Network > > > > 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. > > > > [image: blob:null/71cf5a6a-3841-41ce-a1d4-207b59182189] > > > > 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 > The contents of this e-mail message and > any attachments are intended solely for the > addressee(s) and may contain confidential > and/or legally privileged information. If you > are not the intended recipient of this message > or if this message has been addressed to you > in error, please immediately alert the sender > by reply e-mail and then delete this message > and any attachments. If you are not the > intended recipient, you are notified that > any use, dissemination, distribution, copying, > or storage of this message or any attachment > is strictly prohibited. >
Re: China’s Slow Transnational Network
Yes, CERNET has indeed smaller slowdown period(4 hours) than commodity networks(12 hours), but still has slowdown. Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Mon, Mar 2, 2020 at 2:36 PM David Burns wrote: > Did you compare CERNET with commodity networks? (My > anecdotal observations from a couple years ago suggest that Internet2 to > CERNET is very good when other paths are poor to unusable.) > > --David Burns > > On Mon, Mar 2, 2020 at 7:58 AM Pengxiong Zhu 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 >> >
Re: China’s Slow Transnational Network
> > 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 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 > <mailto:na...@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 >> <mailto:b...@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 > >> b...@6by7.net <mailto:b...@6by7.net> > >> > >> > >> > >>> On Mar 1, 2020, at 9:00 PM, Pengxiong Zhu >>> <mailto:pzhu...@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 d
Re: China’s Slow Transnational Network
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). Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Mon, Mar 2, 2020 at 12:12 PM Ben Cannon wrote: > > On Mar 2, 2020, at 11:38 AM, Pengxiong Zhu wrote: > > Those are good insights. Our first guess is censorship too, and we > discussed the possibilities of censorship side effects in Section 5.1 > *Censorship*. > > It’s the Government doing mandatory content filtering at the border. >> Their hardware is either deliberately or accidentally poor-performing. >> > > 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. > > Maybe... I dunno get rid of the Great Firewall of China? > > > 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. > > My guess is that it’s all the DDoS traffic coming from China saturating >> the links. >> > > 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. > > > 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? > > -Ben. > > 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). > > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > > On Mon, Mar 2, 2020 at 8:11 AM Compton, Rich A > wrote: > >> My guess is that it’s all the DDoS traffic coming from China saturating >> the links. >> >> >> >> *From: *NANOG Email List on behalf of >> Pengxiong Zhu >> *Date: *Monday, March 2, 2020 at 8:58 AM >> *To: *NANOG list >> *Cc: *Zhiyun Qian >> *Subject: *China’s Slow Transnational Network >> >> >> >> 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 connecti
Re: China’s Slow Transnational Network
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 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 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 > b...@6by7.net > > > > On Mar 1, 2020, at 9:00 PM, Pengxiong Zhu 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 > > >
Re: China’s Slow Transnational Network
Those are good insights. Our first guess is censorship too, and we discussed the possibilities of censorship side effects in Section 5.1 *Censorship*. My guess is that it’s all the DDoS traffic coming from China saturating the > links. > 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. 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). Maybe... I dunno get rid of the Great Firewall of China? > What do you mean? Do you mean the slow traffic is to bypass the GFW or the slow traffic is caused by GFW? Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Mon, Mar 2, 2020 at 11:38 AM Pengxiong Zhu wrote: > Those are good insights. Our first guess is censorship too, and we > discussed the possibilities of censorship side effects in Section 5.1 > *Censorship*. > > It’s the Government doing mandatory content filtering at the border. >> Their hardware is either deliberately or accidentally poor-performing. >> > > 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. > > Maybe... I dunno get rid of the Great Firewall of China? > > > 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. > > My guess is that it’s all the DDoS traffic coming from China saturating >> the links. >> > > 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. 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). > > > Best, > Pengxiong Zhu > Department of Computer Science and Engineering > University of California, Riverside > > > On Mon, Mar 2, 2020 at 8:11 AM Compton, Rich A > wrote: > >> My guess is that it’s all the DDoS traffic coming from China saturating >> the links. >> >> >> >> *From: *NANOG Email List on behalf of >> Pengxiong Zhu >> *Date: *Monday, March 2, 2020 at 8:58 AM >> *To: *NANOG list >> *Cc: *Zhiyun Qian >> *Subject: *China’s Slow Transnational Network >> >> >> >> 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
Re: China’s Slow Transnational Network
Yes, the sentence is missing a ‘not’. Sorry about that. It’s not discriminating or differentiating any specific kinds of traffic. On Mon, Mar 2, 2020 at 10:56 AM Valdis Klētnieks wrote: > On Sun, 01 Mar 2020 21:00:05 -0800, Pengxiong Zhu said: > > > 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. > > This sentence is missing a 'not'. However, I can't tell if it's "not > treated equally" > or "not discriminating" > -- Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside
China’s Slow Transnational Network
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
Re: Ownership of Routers on Both Ends of Transnational Links
Sorry for the confusion. I mean the IPs belong to non-Chinese ISPs but are actually controlled/managed by Chinese ISPs. Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Mon, May 13, 2019 at 8:52 AM Christopher Morrow wrote: > On Mon, May 13, 2019 at 11:38 AM Pengxiong Zhu wrote: > > > > Thanks again for your insightful responses! > > > > The case we discuss above is Chinese ISPs renting routers located > outside China and the IPs belong to other ISPs. > > > > I think you are using all of the wrong verbs here... 'renting' does > not make sense here, I'm unclear on what you actually mean, please try > again with a different verb OR more clarifying text. > \ >
Re: Ownership of Routers on Both Ends of Transnational Links
Thanks again for your insightful responses! The case we discuss above is Chinese ISPs renting routers located outside China and the IPs belong to other ISPs. How about the case that the IP belongs to a Chinese ISP and is located in US(from RTT result), can we say it is very likely or definitely owned/operated by the Chinese ISP? Why would some ISP try to rent routers of Chinese ISP in US? For example, a traceroute from Ohio to an IP in China. Hop 17 and hop 18 should be located in US based on the RTT, and yet they belong to a Chinese AS(China Telecom). Does this mean that Chinese Telecom is managing these two hops? HOST:Loss% Snt Last Avg Best Wrst StDev 6. AS???100.65.11.97 0.0% 1002.0 1.0 0.4 12.6 1.3 7. AS???52.93.15.238 0.0% 1002.4 2.0 1.5 11.4 1.1 8. AS???52.93.14.134 0.0% 100 21.9 26.3 4.2 54.4 11.3 9. AS???52.93.14.119 0.0% 1002.6 2.1 1.6 10.8 1.2 10. AS???100.91.27.86 0.0% 100 25.8 26.2 25.6 34.9 1.2 11. AS???54.239.42.197 0.0% 100 25.5 25.9 25.4 35.8 1.5 12. AS???100.91.4.218 0.0% 100 25.9 26.2 25.1 38.3 1.6 13. AS???100.91.4.217 0.0% 100 25.4 26.0 25.3 41.4 2.0 14. AS???100.91.5.85 0.0% 100 25.3 25.8 25.2 29.1 0.9 15. AS???54.239.103.86 0.0% 100 25.6 30.0 25.2 49.1 3.8 16. AS???54.239.103.77 0.0% 100 25.3 25.6 25.2 28.1 0.5 17. AS4134 218.30.53.1 0.0% 100 28.0 29.1 25.2 33.1 2.3 18. AS4134 202.97.50.21 0.0% 100 32.4 29.1 25.2 33.5 2.4 19. AS?????? 100.0 1000.0 0.0 0.0 0.0 0.0 20. AS?????? 100.0 1000.0 0.0 0.0 0.0 0.0 21. AS4134 202.97.94.121 0.0% 100 186.8 185.6 181.8 189.8 2.3 22. AS4816 119.147.222.6 0.0% 100 182.6 183.5 182.4 195.8 1.8 23. AS4816 183.2.182.130 0.0% 100 181.7 183.3 181.5 207.0 3.9 24. AS?????? 100.0 1000.0 0.0 0.0 0.0 0.0 25. AS45102 116.251.113.158 0.0% 100 176.7 177.9 176.5 186.7 2.1 26. AS45102 116.251.115.141 0.0% 100 213.2 213.4 213.1 218.5 0.6 Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Tue, Apr 16, 2019 at 7:37 PM Erik Sundberg wrote: > May sure when you are dealing with transnational links to watch the > latency so you can tell when the link goes international. Just because you > are going from a US Network provider to China Telecom doesn't mean that > your not connecting to them in the united states. > > > > For example a traceroute from Denver to 27.29.128.1 which is an IP in > China Telecom's network. > > It's about 26ms between Denver and Los Angeles. Hop 5 to Hop 6 > > China Telecom connects to GTT in Los Angeles Hop7/8 > > On Hop 8 is in the United State and Hop 9 is across the pacific. Because > the latency goes from 31 ms to 183 ms. > > > Just something to keep in mind. > > > > Packets Pings > Host > Loss% Snt Last Avg Best Wrst StDev > 1. _gateway > 0.0%141.0 1.2 1.0 2.8 0.5 > 2. te-0-0-26.ear2.den1.us.nitelusa.net > 0.0%140.9 1.0 0.8 2.1 0.4 > 3. te-0-0-26.ear1.den1.us.nitelusa.net > 0.0%141.1 1.6 1.1 2.9 0.7 > 4. te-0-0-1-0.cr1.den1.us.nitelusa.net > 0.0%141.0 1.0 1.0 1.1 0.0 > 5. ae1-122.cr0-den2.ip4.gtt.net > 0.0%140.5 1.2 0.3 6.9 2.0 > 6. et-0-0-47.cr3-lax2.ip4.gtt.net > 0.0%14 26.5 26.4 26.2 26.7 0.2 > 7. as4134.lax20.ip4.gtt.net > 0.0%14 27.7 28.7 26.8 30.1 1.1 > 8. 202.97.50.29 > 0.0%14 31.4 30.6 26.8 34.1 2.4 > 9. 202.97.41.129 > 0.0%14 183.3 187.1 183.3 190.8 2.4 > 10. 202.97.94.101 > 0.0%14 187.9 188.6 186.1 211.2 6.8 > 11. 202.97.94.141 > 0.0%13 177.8 180.7 177.2 184.2 2.3 > 12. 202.97.67.54 > 0.0%13 199.5 201.2 197.4 205.1 2.6 > 13. 111.177.110.62 > 0.0%13 205.9 206.3 205.9 208.2 0.7 > 14. 27.29.128.1 > 0.0%13 202.6 202.8 202.5 203.9 0.4 > > > Erik Sundberg > > Sr. Network Engineer > > Nitel > > 350 N Orleans Street > > Suite 1300N > > Chicago, Il 60654 > > Desk: 773-661-5532 > > Cell: 708-710-7419 > > NOC: 866-892-0915 > > Email: esundb...@nitelusa.com > > web: www.nitelusa.com > > -- > *From:* Zhiyun Qian > *Sent:* Tuesday, April 16, 2019 1:02:36 PM > *To:* Erik Sundberg > *Cc:* Pengxiong Zhu; Zhiyun Qian; Zhongjie Wang; Keyu Man > *Subject:* Re: Ownership of Routers on Both Ends of Transnational Links > > Erik, > > Thanks a lot for the information! This is extreme
Re: Ownership of Routers on Both Ends of Transnational Links
> > this is totally true :) but... if the next hop after > chinaunicom-ic-341501-sjo-b21.c.telia.net is a CU ip... it's better > than average chance that the > chinaunicom-ic-341501-sjo-b21.c.telia.net > address is a telia /30 (or /31) on the ptp link between CU/Telia. That > Telia owns the ip space and that PROBABLY the customer identification > is correct. (cu) Yes, in our case, the next hops after all the six routers are some CU IPs. Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Tue, Apr 16, 2019 at 2:34 PM Christopher Morrow wrote: > On Tue, Apr 16, 2019 at 5:19 PM Nimrod Levy > wrote: > > > > > > > > On Tue, Apr 16, 2019, 16:52 Ross Tajvar wrote: > >> > >> I think it's clear that the IPs belong to Telia, but I understood > James's point to be that the router using the IP in question may belong to > China Unicom. (I agree with that, I was not thinking clearly this morning.) > As this is an interconnect link, one side must belong to Telia and the > other to China Unicom. The question, then, is which side are we looking at? > Well, first I want to know how big the subnet is. I assume either /30 or > /31. So, I do a reverse DNS lookup on all the IPs in the surrounding /30 > block: > >> 62.115.170.56 - sjo-b21-link.telia.net > >> 62.115.170.57 - chinaunicom-ic-341501-sjo-b21.c.telia.net > >> 62.115.170.58 - las-b24-link.telia.net > >> 62.115.170.59 - chinaunicom-ic-341499-las-b24.c.telia.net > >> That looks like two /31s. Only one IP in each has the name of China > Unicom in it, so that one is probably in use by China Unicom, and the other > is probably in use by Telia. > > > > that was my point yes. > > > I think we're making a lot of assumptions about how well PTR records are > maintained. All of this could be totally accurate. Or...not... > > this is totally true :) but... if the next hop after > chinaunicom-ic-341501-sjo-b21.c.telia.net is a CU ip... it's better > than average chance that the > chinaunicom-ic-341501-sjo-b21.c.telia.net > > address is a telia /30 (or /31) on the ptp link between CU/Telia. That > Telia owns the ip space and that PROBABLY the customer identification > is correct. (cu) > > -chris >
Re: Ownership of Routers on Both Ends of Transnational Links
Thank you so much for your insightful replies. We are asking the right people! I checked the rest of them, they all seem to be /30 or /31s. 62.115.33.227 jax-b1-link.telia.net 62.115.33.228 telconet-ic-337544-jax-b1.c.telia.net 62.115.33.229 las-bb1-link.telia.net * 62.115.33.230 chinaunicom-ic-302366-las-bb1.c.telia.net 213.248.73.185 adm-b4-link.telia.net 213.248.73.186 riot-ic-303251-adm-b4.c.telia.net 213.248.73.187 213.248.73.188 213.248.73.189 sjo-b21-link.telia.net <http://sjo-b21-link.telia.net> * 213.248.73.190 chinaunicom-ic-127288-sjo-b21.c.telia.net. 152.179.103.250 0.xe-1-2-1.GW7.LAX1.ALTER.NET 152.179.103.250 chinaunicom-gw.customer.alter.net 152.179.103.251 152.179.103.252 152.179.103.253 0.xe-1-0-0.gw2.lax1.alter.net * 152.179.103.254 chinaunicom-gw.customer.alter.net. 63.243.205.89 ix-xe-0-3-3-0.tcore1.sqn-san-jose.as6453.net <http://ix-xe-0-3-3-0.tcore1.sqn-san-jose.as6453.net> * 63.243.205.90 63.243.205.91 63.243.205.92 63.243.205.93 ix-xe-8-2-5-0.tcore1.sqn-san-jose.as6453.net 66.110.59.117 ix-xe-2-1-3-0-0.tcore1.lvw-los-angeles.as6453.net * 66.110.59.118 66.110.59.119 66.110.59.120 66.110.59.121 ix-ae-2-611.tcore1.lvw-los-angeles.as6453.net How about the two IPs(63.243.205.90, 66.110.59.118) that don't have a reserve DNS name? Since they don't have any PTR records. Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside On Tue, Apr 16, 2019 at 1:50 PM Ross Tajvar wrote: > I think it's clear that the IPs belong to Telia, but I understood James's > point to be that the router using the IP in question may belong to China > Unicom. (I agree with that, I was not thinking clearly this morning.) As > this is an interconnect link, one side must belong to Telia and the other > to China Unicom. The question, then, is which side are we looking at? Well, > first I want to know how big the subnet is. I assume either /30 or /31. So, > I do a reverse DNS lookup on all the IPs in the surrounding /30 block: > 62.115.170.56 - sjo-b21-link.telia.net > 62.115.170.57 - chinaunicom-ic-341501-sjo-b21.c.telia.net > 62.115.170.58 - las-b24-link.telia.net > 62.115.170.59 - chinaunicom-ic-341499-las-b24.c.telia.net > That looks like two /31s. Only one IP in each has the name of China Unicom > in it, so that one is probably in use by China Unicom, and the other is > probably in use by Telia. > > On Tue, Apr 16, 2019, 3:50 PM Christopher Morrow > wrote: > >> On Tue, Apr 16, 2019 at 10:59 AM James Jun >> wrote: >> >> > More likely, thease routers are China Unicom's routers in their US POP, >> not managed by VZ/Telia. >> > The /30s in this case are unmanaged IP transit hand-offs, coming in as >> Nx10G or 100G. When your >> > IP transit provider assigns the /30, your router looks like it belongs >> to your upstream, common >> > mistake when interpreting traceroutes[1]. >> > >> >> $ nslookup 62.115.170.56 >> 56.170.115.62.in-addr.arpa name = sjo-b21-link.telia.net. >> >> if you model (as james says) each interconnect as a /30 or /31 ... >> look for the adjacent ip and see the PTR for that ip. >> (the above is your first link example's peer ip) >> >> > [1]: see Page 22 on >> https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf >> > >> > James >> >
Ownership of Routers on Both Ends of Transnational Links
Howdy folks, We are a group of researchers at UC Riverside conducting some measurement about transnational networks. In particular, we are interested in studying the ownership of routers on the two sides of transnational links. We have some concrete questions which we hope someone can shed some light on. Basically when we send packets from US/Canada to China, through traceroute and the RTT of each hop, we can locate the last hop in the US before the packets enter China (*there is a large jump of RTT of 100+ms from this hop onwards*). Oftentimes the ownership of such routers is ambiguous. These hops whose IPs seem to belong to US or European ISPs (*according to BGP info*) but their reverse DNS names have *chinaunicom* in it, which is a Chinese ISP. AS1299 Telia Company AB 62.115.170.57name = chinaunicom-ic-341501-sjo-b21.c.telia.net. 62.115.33.230name = chinaunicom-ic-302366-las-bb1.c.telia.net. 213.248.73.190 name = chinaunicom-ic-127288-sjo-b21.c.telia.net. AS701 Verizon Business 152.179.103.254 name = chinaunicom-gw.customer.alter.net. While the following routers, they don't have a reverse DNS name at all, which seem to be uncommon if they were managed by US or European ISPs but quite common for Chinese ISPs. AS6453 TATA COMMUNICATIONS (AMERICA) INC 63.243.205.90 66.110.59.118 Can anyone confirm that these are indeed managed by the Chinese ISPs (even though they are physically located in the US according to the traceroute and RTT analysis)? Best, Pengxiong Zhu Department of Computer Science and Engineering University of California, Riverside
