On Thu, Apr 23, 2020 at 8:27 AM Dovid Bender <do...@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-faster-over-ipv6/ > > On Thu, Apr 23, 2020 at 11:07 AM Nick Zurku <nzu...@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. >> nzu...@teraswitch.com >> >
