Thanks for responding, and apologies if my post came across aggressive.
As requiem said, it's just frustrating getting 10% of line speed on international connections. And the experience, according to my perceptions and my tests has been worsening over time.
I'll clarify my symptoms:
- My PC is the only device connected to the CPE
- I get full line speed to local resources, including speed tests, locally cached content (like youtube) and local http downloads. I understand this to mean that my line is perfectly fine, and no issues with Vumatel
- Any download or upload sent internationally is severely hamstrung compared to local experience. I undersand this to be due to breakout to international links from CW -> IS -> Peers (please correct me if I am wrong here). Things I have tested are below.
- HTTP downloads from North America (i.e nVidia graphics drivers) - max 7mbps
- Linux or raspberry pi distributions from various providers in EU (HTTP downloads), max 5-7mbps
- Speedtests done to: New York, Chicago, or West Coast - 3-7mbps varying.
- Speed tests done to London (Softlayer as support recommends) - <8mmbps
- Speed tests done to France/Switzerland - 5mbps
- Unable to stream Twitch.tv in high or source (this used to be possible on this exact configuration). Threaded connections using a tool called livestreamer makes this possible for some channels (Twitch partners).
- Other parallel international downloads tend to work far better - including torrents, or HTTP using a download manager (how 2002?)
I have sent this all to support, via emails and in discussions on live chat.
So just a quick note. If concurrent connections solves the issue it has nothing to do with capacity and is a TCP issue. If UDP is the same then it is more evidence of that. This is pretty much the nature of the internet (TCP) and there are some articles on this -
http://blog.performancevision.com/eng/earl/links-between-latency-throughput-and-packet-loss and
http://www.noction.com/blog/network_latency_packet_loss_effects and shows why single threaded TCP connections will always struggle on long distance connections. It is how the internet is built and those articles explain it well.
Twitch is one where it is up to the source, the quality of the server it delivers to from the source, and the quality of their connection from the servers to the IXP locations in London at which point ISPs take over. They don't use proper CDNs for distribution which is a pity and there is next to no local content.
We have then also had issues with a DDoS attack for which there is no simple solution other than to employ mitigation efforts, which involve network management.
But there is a misconception about how the internet works. The internet is dependent on your having sufficient resources to download something (bandwidth, RAM, sufficient I/O on the hardware to process the data at those rates, the protocol supporting those rates, the low latency to support the protocol, the server delivering the content to have sufficient of the exact same resources, and solid internal networking). The ISP takes responsibility for connecting you to one of those servers, at which point if we are the bottleneck you will pick it up easily by running a few simple checks.
In short you can increase international performance using download accelerators which allow you to multi-thread connections to servers that traditionally serve a single-threaded connection. This isn't your ISP throttling or poor performance from the ISP. It's the nature of the internet and TCP. It has a buffer in the OS while it waits for packets to be acknowledged in the correct order. This means that throughput over TCP is very dependent on latency to those servers whereas things like UDP are not (but this is also why UDP is exploited to perform things like DDoS attacks). This is why when you test a torrent (UDP) it will be 100% while TCP instead requires ACK packets and so distance to the server now dictates speeds. On local resources this is not a problem as latency is fine there but the moment you have to get to USA it goes via Europe then USA (there are no direct undersea cables for commercial use between SA and USA yet). Even Europe is a sufficient distance away to cause trouble with TCP connections. We are exploring ways to optimise these for clients even further, but more often than not the bottleneck is not the ISP. So using the charts linked in the above articles you can see that a single thread over 250ms will likely only see single digit downloads, not because the ISP is shaping or throttling but because the nature of TCP requires ACK packets and therefore has a technological limit, and this is why WAN optimisation exists for businesses to deploy in their networks. There are two ways to resolve this or at least get better performance: look at things like tcp optimiser which will try to determine optimal tcp settings for your configuration; and use a multi-thread downloader where possible so you can initiate multiple TCP connections to the same server at the same time.
There is no network management applied to our fibre accounts. Literally every protocol and every packet is treated identically. So UDP and TCP are not treated differently in terms of policy management through the network. But one single dropped packet on a tcp connection over 200ms or 250ms will massively hamper performance. More often than not the buffer fills too quickly as well, or is too small. More often than not the operating system is set for stability rather than high performance. High performance has its drawbacks too. And changing the tcp settings for high performance has its own risks dependent on your hardware and drivers and operating system. So this is not something your ISP can simply say "do x, y, and z and all will be fine, especially considering the thousands of drivers from hundreds of manufacturers out there, as well as the different tcp stacks in various operating systems and versions.
As an ISP we take responsibility for transit from your connection's CPE to other servers. In much the same way as we cannot own and control those servers, we also cannot own, control, nor make changes to your internal network and the connected devices, and making changes there are things that you should consider by your own accord and at your discretion. We have some devices launching soon which will allow us to assist in this regard n an effort to help customers to make these changes with your permission, but they cannot get to your operating system which often plays the most important role. If the OS halves the receive window and doesn't restore it after one dropped packet, that download speed may be halved or worse for its entire duration, no matter how much bandwidth we have spare for you. The OS has already limited you, as it controls the transfer to your PC/devices. Then you should also bear in mind that very few servers can even deliver a full 100Mbps to all people connecting to it. If 3 people are downloading at once they require a dedicated or E-WAN link capable of 300Mbps, which is not cheap. You will never find "free movies and tv shows" using this sort of model. They use shared hosting which has the lowest priority on the host's outbound WAN links and splits traffic between all shared hosts accordingly. In fact most websites on the internet and most downloads reside on shared hosting, and the hosting provider shapes that traffic on a best effort basis to incoming and outgoing connections.
There are lots of things that impact performance, and when it comes to fibre and high speeds there is an expectation that everything should come down at full line speed no matter what. Unfortunately that is simply not the reality of how the internet works, by and large, and we can say without a shadow of a doubt that we have so much spare capacity that it would be 100% pointless implementing traffic management in any way and "creating" these problems for ourselves, for zero benefit. To be frank, there is an expectation vs reality problem which creates most of the problems. It doesn't mean there are not things that we can do. We are busy investigating options for optimising certain things on customers' behalves to assist over and above just our network. And we're naturally taking a very hard line approach to any attacks on the network as well.
I hope this helps to explain the technical side of why sometimes expectation vs reality issues are not as a result of the ISP, at least on fibre.
