I am saying this well knowing the conduct of Google at W3C and whatwg, and which I believe you know too.
Now, nobody of httpbis raised a red flag, and challenged performance figures of HTTP/2 before it became a standard.
Ok, I will take that grumbling on internet forums is a non-solution. How would you suggest contributing to HTTPbis process without flying engineers around the world all year long to attend IETF meetings?
On the matter of QUIC — my biggest discontent with it is that these guys basically recreated SCTP (and botched it at that,) but did it in UDP, without taking advantage of most exiting OS level, and hardware level performance optimisation. There is no chance at all hardware makers will put any effort to support offloading somebody's proprietary weekend project into hardware, and without that it has no chance at adoption, and everybody will be stuck at HTTP/2 now because CDNs are very happy with it, and browsers can't roll back its support.
HTTP/4 is needed now, it needs to be built over SCTP to have any chance at getting hardware offloading.
I don’t know Google’s conduct at whatwg / w3c. I’ve never been to either of them. (My understanding is whatwg is invite only or something? Is that right?)
As for flying people around the world, most of the actual work of the IETF happens on the mailing lists and (in the case of httpbis) on the http GitHub issue tracker. You can attend the meetings virtually, and they go to great length to include virtual attendees - though it’s never quite the same as talking to people in person over drinks or in the corridors. If you think the http working group isn’t taking performance metrics seriously enough, it sounds like you have something really important to contribute to the standards group. That voice and perspective is important.
I agree with you about SCTP being a missed opportunity - though I suspect quic will get plenty of adoption anyway. And I’m sure there’s a reason for not using sctp - I think I asked Roberto Peon a couple of years ago at IETF but I can’t remember what he said. He’s certainly aware of sctp. (For those who don’t know, he’s one of the original authors of quic/spdy from when he was at Google.)
I agree that quic will probably never hit 100% of global web traffic, but I wouldn’t be surprised if it surpassed 50% within a decade or so. And there’s some positives from that - it’s nice to put pressure on internet vendors to allow opaque udp packets to float around the net. Hardware offload aside, that increases the opportunity for more sctp-like protocols on top of udp in the future. It’s just a shame any such attempts will need to layer on top of udp.
I am very serious about hardware offload being supercritical for adoption.
Not having it, means CDNs must have 4-5 times more CPU power, on top of natural internet traffic growth. Saying "buy 5 times more servers" will not fly
HTTP/2 is such a hit with CDNs exactly because it let them do more traffic with less servers, though with worse end user experience unless for kind of people who get gigabit at home.
Now, nobody of httpbis raised a red flag, and challenged performance figures of HTTP/2 before it became a standard.
Ok, I will take that grumbling on internet forums is a non-solution. How would you suggest contributing to HTTPbis process without flying engineers around the world all year long to attend IETF meetings?
On the matter of QUIC — my biggest discontent with it is that these guys basically recreated SCTP (and botched it at that,) but did it in UDP, without taking advantage of most exiting OS level, and hardware level performance optimisation. There is no chance at all hardware makers will put any effort to support offloading somebody's proprietary weekend project into hardware, and without that it has no chance at adoption, and everybody will be stuck at HTTP/2 now because CDNs are very happy with it, and browsers can't roll back its support.
HTTP/4 is needed now, it needs to be built over SCTP to have any chance at getting hardware offloading.