Re: China’s Slow Transnational Network
Note, of course, further, that "the GFW" is not a single appliance, nor even a standard, common appliance. There are very different "GFWs" based on which link you're looking at, which telco it is, etc. Indeed, usually traffic to Hong Kong is effected much less by the GFW than other links (though still passes through *a* GFW). I've also found traffic destined to Khabarovsk (depending on the routing) to pass through GFWs which rarely cause issue. Matt On 3/3/20 1:28 PM, Rubens Kuhl wrote: > > > On Tue, Mar 3, 2020 at 3:23 PM Jakob Heitz (jheitz) via NANOG > mailto:nanog@nanog.org>> wrote: > > I can corroborate that. I visited China in August 2019 and had > terrible internet performance to sites outside of China. This was > both with mobile and wifi at the homes of two friends, one in > Heilongjiang and the other in Beijing. When I visited in February > 2015, it was much better. Both times, I was using VNC on the company > VPN. This does not use much bandwidth, but is quite latency sensitive. > > > GFW has some different settings that they use, similar to "ThreatCon"... > if civil unrest is happening, its working is changed. During party > conventions, they change it too. > So when a foreign visits China, that experience might be different from > one visiting during a different time period. > > Also, some hotels that only accept international guests backhaul traffic > thru Hong Kong, providing an experience that looks much closer to > US/Europe broadband. > > > Rubens > >
Re: RADB account deletions
> On Mar 3, 2020, at 1:39 PM, Job Snijders wrote:
>
> On Tue, Mar 03, 2020 at 11:22:35AM -0700, Clinton Work wrote:
>> It looks like the former Allstream RADB account (MAINT-AS15290) and
>> all associated route objects were removed from RADB today. The
>> deletion mainly impacts Canadian route objects registered by the
>> former Allstream (now Zayo). Q9 Networks MAINT-AS12188 was deleted
>> at the same time.
>
> For those interested, I think this is roughly what was deleted:
>
> snapshot/20200302-0001/whois.radb.net$ awk 'BEGIN {RS=""; FS="\n"}
> /MAINT-AS15290/ {print $0 "\n"}' radb.db > MAINT-AS15290.2020.03.02.txt
>
> file @ http://instituut.net/~job/MAINT-AS15290.2020.03.02.txt
>
> I'm sure RADB staff can restore was appropriate if they are contacted.
>
I know that ARIN had some IRR related issues in the last week, but you may want
to move objects there if feasible.
- Jared
Re: RADB account deletions
On Tue, Mar 03, 2020 at 11:22:35AM -0700, Clinton Work wrote:
> It looks like the former Allstream RADB account (MAINT-AS15290) and
> all associated route objects were removed from RADB today. The
> deletion mainly impacts Canadian route objects registered by the
> former Allstream (now Zayo). Q9 Networks MAINT-AS12188 was deleted
> at the same time.
For those interested, I think this is roughly what was deleted:
snapshot/20200302-0001/whois.radb.net$ awk 'BEGIN {RS=""; FS="\n"}
/MAINT-AS15290/ {print $0 "\n"}' radb.db > MAINT-AS15290.2020.03.02.txt
file @ http://instituut.net/~job/MAINT-AS15290.2020.03.02.txt
I'm sure RADB staff can restore was appropriate if they are contacted.
Kind regards,
Job
Re: China’s Slow Transnational Network
On Tue, Mar 3, 2020 at 3:23 PM Jakob Heitz (jheitz) via NANOG < nanog@nanog.org> wrote: > I can corroborate that. I visited China in August 2019 and had terrible > internet performance to sites outside of China. This was both with mobile > and wifi at the homes of two friends, one in Heilongjiang and the other in > Beijing. When I visited in February 2015, it was much better. Both times, I > was using VNC on the company VPN. This does not use much bandwidth, but is > quite latency sensitive. > > GFW has some different settings that they use, similar to "ThreatCon"... if civil unrest is happening, its working is changed. During party conventions, they change it too. So when a foreign visits China, that experience might be different from one visiting during a different time period. Also, some hotels that only accept international guests backhaul traffic thru Hong Kong, providing an experience that looks much closer to US/Europe broadband. Rubens
RADB account deletions
It looks like the former Allstream RADB account (MAINT-AS15290) and all associated route objects were removed from RADB today. The deletion mainly impacts Canadian route objects registered by the former Allstream (now Zayo). Q9 Networks MAINT-AS12188 was deleted at the same time. -- Clinton Work
RE: China’s Slow Transnational Network
I can corroborate that. I visited China in August 2019 and had terrible internet performance to sites outside of China. This was both with mobile and wifi at the homes of two friends, one in Heilongjiang and the other in Beijing. When I visited in February 2015, it was much better. Both times, I was using VNC on the company VPN. This does not use much bandwidth, but is quite latency sensitive. -Original Message- Date: Sun, 1 Mar 2020 21:00:05 -0800 From: Pengxiong Zhu 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
NANOG 79 Call For Presentations
Vincent Celindro Thu, Nov 21, 2019, 5:57 PM to NANOG-announce, nanog Dear NANOG Community, In NANOG tradition - The NANOG Program Committee (PC) is excited to announce that we are accepting proposals for all sessions at NANOG 79 in Boston, Massachusetts, June 1st - 3rd, 2020. As mentioned during the community meeting at NANOG 78 in San Francisco, the Call For Presentations, CFP, is now open all year round, for current and future meetings. Below is a summary of key details and dates for the CFP, which can also be found at https://www.nanog.org/meetings/nanog-79/submit-presentation/ Given by many of the industry’s top minds, presentations at NANOG meetings are meant to spark the imagination, encourage dialog, and drive new solutions to our greatest networking challenges. The PC is currently seeking proposals, and also welcomes suggestions for speakers and topics. Presentations may cover current technologies, soon-to-be deployed technologies, and industry innovation. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations should not be promotional, or discuss proprietary solutions. We understand you may have concerns regarding the COVID 19 coronavirus. To date, the areas of the world most impacted by the virus are outside the North American region, which NANOG serves. The NANOG Board of Directors and executive team are closely watching the latest news reports as information about the virus rapidly changes, and how this may or may not impact the upcoming conference. There is no information at this time that suggests we should cancel NANOG 79, but we assure you we'll keep the entire NANOG community up to date as information changes, and we learn more. The primary speaker, moderator, or author should submit a presentation proposal and abstract via the Program Committee Tool at: https://www.nanog.org/meetings/submit-presentation/ - Sign in with your Profile Account - Select the type of talk you propose to present, and complete the title and abstract Timeline for submission and proposal review: - Submitter enters abstract (and draft slides if possible) in Program Committee Tool prior to the deadline for slide submission. - PC performs initial review and assigns a “shepherd” to help develop the submission — within 2 weeks. - Submitter develops draft slides of talk if not already submitted with the initial proposal. Please submit initial draft slides early — the PC does not evaluate submissions until draft slides are available for review. A NANOG slide template as well as presentation guidelines are available here. https://www.nanog.org/participate/presentation-guidelines/ - Panel and Track submissions should provide a topic list and intended/confirmed participants in the abstract. - PC reviews the slides and continues to work with Submitter as needed to develop the topic. - Draft presentation slides should be submitted prior to the published deadline for slides (April 13th, 2020). - PC evaluates submissions to determine presentations for the agenda (posted by May 18th, 2020). - Agenda assembled and posted. - Submitters notified. - Final presentation slides must be submitted prior to the published deadline for slides (May 25th, 2020). If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the PC ( nano...@nanog.org), and a representative will respond to you in a timely manner. Otherwise, submit your talk, keynote, track, or panel proposal to the Program Committee Tool at your earliest convenience. We look forward to reviewing your submission! Key dates for NANOG 79: Date Event/Deadline March 2, 2020 CFP Opens March 30, 2020 Standard Registration Begins April 13, 2020 CFP Deadline: Presentation Slides Due May 4, 2020 CFP Topic List & NANOG Meeting HIghlights Page posted May 11, 2020 Late Registration Begins May 18, 2020 NANOG 78 Agenda Posted May 25, 2020 Speaker FINAL presentations DUE (NO CHANGES accepted after this date) May 31, 2020 Lightning Talk Submissions Open, Onsite Registration Begins Final slides must be submitted by Monday, May 25th, 2020, and no changes will be accepted between that date and the conference. Materials received after that date may be updated on the website after the completion of the conference. We look forward to seeing you in Boston in June! Sincerely, Vincent Celindro - PC Chair On behalf of the NANOG Program Committee
Equinix IX Dallas Legacy Route Servers Decommissioning - Subnet Expansion
PSA: For anyone on the Equinix IX in Dallas who may have missed the announcements - The subnet in Dallas was expanded to a /23 and there are new MLPE route servers. The old route servers will be decommissioned this week. >From Equinix: "IBX(s): DA1,DA10,DA2,DA3,DA4,DA6,DA7,DA9,DA99 DESCRIPTION:NOTICE: THE LEGACY MLPE AND ROUTE COLLECTOR SERVERS WILL BE DECOMMISSIONED 5-MAR-2020 Equinix expanded the DA IX subnet from a /24 to a /23 on 25-JUN-2019. Equinix engineers also updated the MLPE and Route Collector IPs and subnet mask from /24 to /23. Customers that have not already done so, will need to update their subnet mask and peering IP address for the MLPE/RC servers to reflect the newly expanded subnet of 206.223.118.NNN/23. BGP Sessions are preconfigured for all MLPE/RC participants on the new servers, but if you have issues bringing up your sessions please contact us. A Status page is published at the following link https://ix.equinix.com/home/ip-migration/da/ " -- __ David Miller dmil...@tiggee.com
Re: Take-Two Interactive Software NOC Contact
Your customers haven't been DDoS Attacked by any chance? There is a TCP-AMP attack method, which will falsely flag any IP for abuse. And it seems like Prolexic, Akamai & other services are using some abuse blacklist system. On 02.03.2020 23:04:31, Tim Nowaczyk wrote: Network Engineer for a small ISP here. Our customers seem to be having connectivity issues with Take-Two Software, specifically NBA 2k20. Traceroute makes it to Akamai Prolexic before being dropped. Does anyone have contact info for someone at Take-Two? Thanks, Tim Nowaczyk -- Timothy Nowaczyk | Senior Network Manager office 703.554.6622 [tel:703.554.6622] | mobile 571.318.9434 [tel:571.318.9434] [http://www.allpointsbroadband.com/] [http://www.allpointsbroadband.com/]
Re: QUIC traffic throttled on AT&T residential
On Mon, Mar 2, 2020 at 4:29 PM Daniel Sterling wrote: > Also: I think ipv6 isn't working for me cuz it's being dropped by a switch > I'm using! > > I will swap that out / remove that and try ipv6 again OK, ipv6 is working for me now. The switch that was dropping ipv6 traffic was: Windows 10 (1909) hyper-v switch! I was running Windows -> hyper-v -> openwrt, since openwrt's kernel didn't have support for a USB NIC I'm using. I know, this is ridiculous. I switched to ubuntu 19.10 -> kvm -> openwrt, and ipv6 works out of the box. Next step may be to see if I can get ipv6 working with just plain ubuntu (and to stop using USB NICs) -- Dan
RE: China’s Slow Transnational Network
Hi Pengxiong, The largest ISP in China, China Telecom offers 3 types of their IP Transit service 1. Normal China Telecom (AS4134), poor quality because of overselling their bandwidith. 2. CN2 GT (AS4809) 3. CN2 GIA (AS4809) CN2 GT (Global Transit) is cheaper than CN2 GIA (Global Internet Access), CN2 GIA is the most expensive but with stable and best network quality. Have you tested all of these 3 types? According to your pdf, only Alibaba Cloud in Hong Kong and Singapore has CN2 connectivity. Another reason is the population of China, which is around 1.4 billion, and only 3 major ISPs (CT, CU and CM) can offer service to home users in China. Regards, David From: NANOG On Behalf Of Pengxiong Zhu Sent: Tuesday, March 3, 2020 6:55 AM To: Compton, Rich A Cc: North American Network Operators' Group ; Zhiyun Qian Subject: 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 mailto:rich.comp...@charter.com>> wrote: My guess is that it’s all the DDoS traffic coming from China saturating the links. From: NANOG Email List mailto:nanog-boun...@nanog.org>> on behalf of Pengxiong Zhu mailto:pzhu...@ucr.edu>> Date: Monday, March 2, 2020 at 8:58 AM To: NANOG list mailto:nanog@nanog.org>> Cc: Zhiyun Qian mailto:zhiy...@cs.ucr.edu>> 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. 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
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
On 2/Mar/20 07:00, Pengxiong Zhu wrote: > 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). Most countries in Africa do not implement great big firewalls. Our problems are quite different :-\... Mark.
