I fully expect to be down voted for saying this, but the way that the Internet works means that you have no guarantee that communication between two computers via Internet Protocol packets will operate at either's last mile connection speed or even operate at all. When you get an Internet connection from an ISP, what you are getting is a connection to their network. Access to the other networks that make up the Internet is something that they both do not guarantee and cannot guarantee. The only reason that you get it at all is that if most of the others were not typically reachable from them, they would lose business to an ISP from which most of the others are typically reachable. If the links degrade, it only matters to them when they perceive inaction as impacting their profits more than doing something. In some cases, the ISPs cannot reasonably do anything about because the owner of the other network refuses to provide sane terms for doing something or even allow access at all. For example, China and the US were connected by a 155Mbps link 10 years ago because Chinese ISPs wanted non-Chinese ISPs to pay for transit connections at >10 times the going rate. In the case of the 25.0.0.0/8 block, the owner is the British government, which refuses to allow interconnection. Consequently, it is simply not possible for any commercial ISP to provide quality access to every other network on the Internet or even provide access at all, even before we get to the cases that cerrain ISPs are jerks, like Verizon was with Netflix.
I was affected by that peering dispute too. That lead me to research it, understand it and workaround it. Consequently, I use that knowledge to implement workaround whenever a peering issue affects me.
To name one, I observed 1.3 second average RTTs between Shanghai and New York when I was visiting family there in 2014. My research into the Verizon peering disputes prepare me fairly well for dealing with it. I initially used OpenVPN over TCP and my pings were running inside the VPN tunnel. Packet loss was typically in the range of 10% to 20%. There were occasional latency spikes to 30 seconds. Switching to UDP lowered latencies to ~300 ms in either case, but bandwidth was rather low. I forget how bad it was in absolute terms, but I can say that it was too bad to use YouTube or even VoIP. What helped was routing through servers in Japan.
The trick was to do a perverse variation on a NAT where the LAN and WLAN interfaces are the same and the NAT is effectively a proxy for a port on a remote system. It works well for routing around peering disputes when you can get a VM in a place where there are not peering disputes between the local ISP and the VM provider and the VM provider and the destination. Trace route results at the time suggested that Japanese ISPs appeared to maintain both sides of the underwater link between them and China while US ISPs only control the network sockets at the Internet exchanges in the US. Routing through the Japanese internet backbone presumably eliminated the congested US-Chinese peering links from the path, which showed because packet loss went into the single digits. I do not remember the exact numbers, but it also put speed between 1Mbps and 10Mbps. That was enough for me to make VoIP calls to NY while I was visiting family in Shanghai and YouTube was usable and even load YouTube videos.
However, the connection was still bad enough to make Verizon's peering dispute with Netflix look mild in comparison. There were occasional latency spikes to 30 seconds, which appeared to be from buffer bloat in the great firewall. Google search results on the Chinese backbone at the time suggested that the entire county also appeared to have a star-like network topology for its backbone, with the exception being that Hong Kong was on the outside of that. My trace route results from Shanghai then were consistent with it.
Another OSS developer in Shanghai informed me at the time that the three major ISPs in China have peering disputes among themselves despite the Chinese government owning all three. He claimed that communications over his 100Mbps last mile connection at his house with his employer's office operated at dial up speeds because of that. I did not confirm that, but I believed him. What I saw of Chinese Internet connectivity while I was ther struck me as being incredibly terrible.
I still remember how bad things were with Verizon and Netflix. However, the reality is that things could have been many times worse like they were in China when I was there in 2014. At least with Verizon and Netflix, you had the option of the HE tunnel broker. In China, I saw ISPs using carrier grade NAT, such that using IPv6 via the tunnel broker is impossible. That is not to say that IPv6 via the tunnel broker is some sort of magic cure for issues. The only reason IPv6 via the tunnel worked during that dispute was because there was no congestion between Hurricane Electric and Verizon as well as between Hurricane Electric and Netflix. If many people had tried using it, it would likely have degraded too.
Whether it's what they intended to sell or not, ISPs, through their own marketing material, sell a connection to "the Internet", and unfortunately for them that term cannot fairly be applied to just Comcast's network anymore (though it would make for a comical court case).
If they can't provide what is advertised, specifically "Internet access", then it's false advertising and I expect, and will fight for, my money back.
The real issue is that those of us that are not ASN operators are at the mercy of those who are. The only true solution is finding an ASN operator that has user interests at heart. Municipal fiber is probably a good example of that. There are other ways (all involving getting an Internet backbone connection), but they are not cost competitive with last mile distribution.
A workaround would be to rely on an IPv6 tunnel broker or a VPN tunnel to a VM in some datacenter. As long as the tunnel is unaffected by peering disputes, your traffic over it will live at the other side of the divide between content producers and consumers. That gives a far better experience than relying on a last mile operator to give you access to the broader Internet.
Speaking of which, does anyone know when hacker news will support IPv6?
I was affected by that peering dispute too. That lead me to research it, understand it and workaround it. Consequently, I use that knowledge to implement workaround whenever a peering issue affects me.
To name one, I observed 1.3 second average RTTs between Shanghai and New York when I was visiting family there in 2014. My research into the Verizon peering disputes prepare me fairly well for dealing with it. I initially used OpenVPN over TCP and my pings were running inside the VPN tunnel. Packet loss was typically in the range of 10% to 20%. There were occasional latency spikes to 30 seconds. Switching to UDP lowered latencies to ~300 ms in either case, but bandwidth was rather low. I forget how bad it was in absolute terms, but I can say that it was too bad to use YouTube or even VoIP. What helped was routing through servers in Japan.
The trick was to do a perverse variation on a NAT where the LAN and WLAN interfaces are the same and the NAT is effectively a proxy for a port on a remote system. It works well for routing around peering disputes when you can get a VM in a place where there are not peering disputes between the local ISP and the VM provider and the VM provider and the destination. Trace route results at the time suggested that Japanese ISPs appeared to maintain both sides of the underwater link between them and China while US ISPs only control the network sockets at the Internet exchanges in the US. Routing through the Japanese internet backbone presumably eliminated the congested US-Chinese peering links from the path, which showed because packet loss went into the single digits. I do not remember the exact numbers, but it also put speed between 1Mbps and 10Mbps. That was enough for me to make VoIP calls to NY while I was visiting family in Shanghai and YouTube was usable and even load YouTube videos.
However, the connection was still bad enough to make Verizon's peering dispute with Netflix look mild in comparison. There were occasional latency spikes to 30 seconds, which appeared to be from buffer bloat in the great firewall. Google search results on the Chinese backbone at the time suggested that the entire county also appeared to have a star-like network topology for its backbone, with the exception being that Hong Kong was on the outside of that. My trace route results from Shanghai then were consistent with it.
Another OSS developer in Shanghai informed me at the time that the three major ISPs in China have peering disputes among themselves despite the Chinese government owning all three. He claimed that communications over his 100Mbps last mile connection at his house with his employer's office operated at dial up speeds because of that. I did not confirm that, but I believed him. What I saw of Chinese Internet connectivity while I was ther struck me as being incredibly terrible.
I still remember how bad things were with Verizon and Netflix. However, the reality is that things could have been many times worse like they were in China when I was there in 2014. At least with Verizon and Netflix, you had the option of the HE tunnel broker. In China, I saw ISPs using carrier grade NAT, such that using IPv6 via the tunnel broker is impossible. That is not to say that IPv6 via the tunnel broker is some sort of magic cure for issues. The only reason IPv6 via the tunnel worked during that dispute was because there was no congestion between Hurricane Electric and Verizon as well as between Hurricane Electric and Netflix. If many people had tried using it, it would likely have degraded too.