[the8472]

I'm not sure how that really is a problem. I am writing this from a box that has IPv6 and most of the latest TCP stuff including BBR, ECN and TFO. It took a while until we got to that point, but here we are. In the past we were able to wait too, why not now?

[virattara]

I think the time taken by end-users/customers using your app will be of more concern here since they will take significantly more time to upgrade their devices to a new transport protocol or fixes in existing ones. QUIC will enable us to restrict such updates to the developer level.

[the8472]

That doesn't really explain what changed, where the urgency is coming from. Also note that some TCP improvements are sender-side only, so you only need to upgrade your server, not all client devices.

[afiori]

The urgency is coming from mobile networks and high reliance on low latency for user engagement.

Also even if we assume that 50% of all internet users have access the most modern protocols as soon as reasonable we still care about how quickly the next half will upgrade.

And in a sense I agree with this vision of the internet. On one hand the internet could be a super optimized distributed communication network with a lot of embedded functionality (I really like the concept of content-centric-networks/name-centric-networks) on the other hand the internet could be a dumb many-ended pipe (the IP protocol)

In terms of how I use the internet in practice I always prefer the dumb pipe model.

[the8472]

The upgrade problem is something that google created with android devices being stuck on old kernels, now they're trying to paper over that mess by moving things to userspace. That may solve this particular problem but it creates a new maintenance nightmare with hundreds of different applications bringing their own congestion control and different transport implementation on top of dozens of differnet TLS libraries. It seems like a little more patience and ensuring that devices remain upgradable could give us most of the advancements without the downsides.

[afiori]

That is a possible source of error, still there is the issue of network devices that implement ossified versions of internet standards. For example when they tried to use different kinds of compression in unencrypted HTTP it came out that a lot of middleboxes would simply "fix" the content-encoding header to be either gzip or deflate, regardless of that making it illegible.