I got a problem with my AT&T Fiber service at the house. We pay for a 500 Mbps plan, and I can get 600 Mbps up and down via ethernet on speedtest (probably due to over provisioning). However, I can only download stuff about 8 MB/s from most places. I believe this to be an internal issue as whenever I connect to any VPN service, I can get the full 600 Mbps. Furthermore, some servers are able to serve me at full speed, but this is rare. Usually GitHub git servers can upload to me at full speed, while GitHub tar balls are uploaded to me at about 8 MB/s.

Seeing as everyone in here has a lot of bad experiences with ISPs, should I straight up skip attempting to talk with them at all and go for an FCC complaint/government complaint?

▲

rft an hour ago | parent | next [-]

At this point escalating, or threatening to, might be the better option. But I can't help trying to figure out how to solve a people/organizational problem with a technological solution.

Github is still famously IPv4 only. I don't know if there is a split between the SSH (if you use SSH to access the repos) and HTTPS (the tarballs) setup on their end, so maybe you get full speed on IPv6 and limited on IPv4 (or the other way around). Try disabling IPv6 on your end, if the speeds match then this might be it. If IPv6 is fast using an IPv4 gateway that tunnels via an IPv6 VPN might be a workaround.

I also had a similar problem a while back. Some speedtests showed more bandwidth than I could get in regular HTTPS downloads. I could get multiple downloads running at the same time that in total added up to the expected speed. In my case the line was just lossy enough (TCP retransmits in Wireshark) for TCP to never scale up its window size properly beyond a certain limit per connection. I verified this by running iperf in TCP and UDP against a gigabit server, UDP reached near full speed because it didn't care about a few lost packages. Working around that issue might be a bit harder, maybe [1] via [2] can provide some ideas to look into.

[1] https://github.com/apernet/tcp-brutal

[2] https://news.ycombinator.com/item?id=38164574

▲

ted_dunning 4 hours ago | parent | prev [-]

If you can't document your attempts to document and resolve the issue in your FCC complaint it will have far less credibility.

▲

hurricanepootis 3 hours ago | parent [-]

Ok, thank you! I'm gonna gather as much documentation as I can.

Considering the fact that I get full speeds everywhere whenever I'm using a VPN, am I right to assume that there is an issue with AT&T's internal routing? And, that issue doesn't effect every path? I'm not really an expert at doing networking stuff, but I wanna gather as much empirical data to construct a report and do statistical tests n stuff.

	▲	ycombiredd 2 hours ago \| parent [-]
		My first guess wouldn't be routing, but traffic-shaping. Perhaps the VPN you use is on a protocol/port that isn't outright rate-limited and since ATT can't peak inside your tunnel to see what you are doing with the bandwidth, it avoids any QoS/shaping/limiting that your non-VPN connection is subjected to.