> Undercutting a competitor’s latency by as little as 250ms is considered a competitive advantage in the industry.
I'm pretty sure my director would tell you that number today is closer to 10ms.
> While ISPs compete primarily on the basis of peak bandwidth offered, bandwidth is not the issue.
As the submission makes evident (and you are well aware), this is still very much the case today.
> For instance, c-latencies from the Eastern US to Portugal are in the 30ms vicinity, but all transatlantic connectivity hits Northern Europe, from where routes may go through the ocean or land Southward to Portugal, thus incurring significant path ‘stretch’.
Sadly, this still holds today. Almost all cables land in UK / Ireland, although MAREA does land in northern Spain, and there are a couple others in flight.
> Most routes to popular prefixes are unlikely to change at this time-scale in the Internet
Ha. Maybe at the level of ASNs, but we certainly perform traffic engineering on much smaller timescales (see https://www.cs.princeton.edu/courses/archive/fall17/cos561/p...).
Protocol improvements have definitely come a long way in the past decade. QUIC is now an IETF standard, with 0-rtt session resumption as you mention, as well as initial congestion window bootstrapping to reduce the number of round trips in slow start. But we haven't made much progress in many places that the article points out are in need of improvement.
I think the focus on speed-of-light in vacuum and the development of a c-ISP is not as useful for discussing the internet backbone, at least until we have viable replacements for fiber that are able to satisfy the same massive bandwidth requirements. Even ignoring YouTube video serving, we still have many terabits of egress globally, so the 80Gbps capacity target is not anywhere close to enough, even for 1% of our traffic in the US. That's barely enough to serve 100k qps of 100kB files. (A full page load of www.google.com with all resources clocked in around 730 kB transferred over the network, according to Chrome devtools. That's probably an argument that we should be making our home page lighter, but more than 90% of that is cached for future requests.)
And just accounting for 2x peak-to-average ratio absolutely doesn't account for inorganic demand induced by events like the Super Bowl or a popular video game release (https://www.pcgamer.com/baldurs-gate-3-launch-slams-into-ste...).
