On Thu, Apr 23, 2020 at 8:27 AM Dovid Bender <dovid@telecurve.com> wrote:
We have customers in CT with the same issues. When did this start?
Seems to have started 5 years ago when we ran out of ipv4 and all comers needed to embrace ipv4 life-support mechanisms https://www.arin.net/vault/announcements/2015/20150924.html The e2e ipv6 internet being faster and more robust than life-supported, bot-ridden, and scarce ipv4 is.... a feature, not a bug. https://www.internetsociety.org/blog/2015/04/facebook-news-feeds-load-20-40-...
On Thu, Apr 23, 2020 at 11:07 AM Nick Zurku <nzurku@teraswitch.com> wrote:
Hello all,
I would appreciate if someone from Comcast could contact me about this.
We’re having serious throughput issues with our AS20326 pushing packets to Comcast over v4. Our transfers are either the full line-speed of the Comcast customer modem, or they’re seemingly capped at 200-300KB/s. This behavior appears to be almost stateful, as if the speed is decided when the connection starts. As long as it starts fast it will remain fast for the length of the transfer and slow if it starts slow. Traces seem reasonable and currently we’ve influenced the path onto GTT both ways. If we prepend and reroute on our side, the same exact issue with happen on another transit provider.
This issue does not affect v6 and that is full speed on every attempt. This may be regionalized to the Comcast Pittsburgh market.
This is most widely affecting our linux mirror repository server: http://mirror.pit.teraswitch.com/ Our colocation customers who are hosting VPN systems are also noticing bottlenecks have started recently for their Comcast employees.
-- Nick Zurku Systems Engineer TeraSwitch, Inc. nzurku@teraswitch.com