> Yes congestion will need to be dealt with, but that's
> not really an issue: the same recipes that work for
> TCP can be re-used.
Every application reimplements its own idea of congestion detection and avoidance? I dont think thats a good idea. A whole lot of work is today
done to grant fairness between streams of data. This imho only works as long as they all play with the same rules.
And reimplementing the same semantics is exactly QUIC trys to avoid.
Ideas like ECN will not work for QUIC as ECN needs bits in the TCP header. Instead of working around the problem of RTT, Bufferbloat and TCP congestion detection push stuff like RED+ECN and AQM.
Yes - its the providers networks, the 802.11 stacks, DSL Routers etc. It'll take longer than simply pushing a new Browser every 4 Weeks out.
Its not a problem with niche applications like bittorrent - put pushing a new protocol with completely untested congestion behaviour out to millions of clients and shifting the majority of traffic from TCP to UDP will present us with a bunch of interesting new problems.
Whats next? Hangout replaces SMTP, DNS over QUIC, G+ instead of IGMP? ProtoBuf in UDP instead of POP/IMAP?