> QUIC will increase the size of transport and this affects capped customers. Will it? The TCP header is 20 bytes, the UDP header is 8 bytes. And in as far as

> QUIC will increase the size of transport and this affects capped customers. Will it? The TCP header is 20 bytes, the UDP header is 8 bytes. And in as far as packets are bigger, will it actually cause more traffic? For example, you have muliplexing of streams over one connection without head of line blocking, while with HTTP over TCP you need multiple TCP connections and thus multiple TLS connections for that, for example. Also, QUIC allows you to change UDP endpoints without the need to establish a new connection. I wouldn't be so sure it needs more bandwidth. Now, arguably, building directly on IP would be better, but that is unfortunately an option that ISPs and other manufacturers and operators of middleboxes have destroyed, so I think you can't really blame QUIC for that. There really is no realistic way to evolve beyond the limitations of TCP unless you build on UDP. If QUIC succeeds and if we manage to move to IPv6 and get rid of NAT, though, I guess there might be a chance to one day see "QUIC on IP"--as far as the protocol is concerned, it should be trivial to adopt it for direct IP transport.