Earlier quoted context omitted.
It compares in the way that there's not a single SCTP web server implementation compared to QUIC. People here say that we should use HTTP/2 over SCTP, no protocol will be adopted if there's no good implementations of it.
A WebRTC "RTCDataChannel" is an SCTP-over-DTLS-over-UDP stack, and webservers exist to stream to these. They're just mostly proprietary, existing as part of vertically-integrated stacks like that of Google Hangouts (i.e. its "app sharing" feature.)
Some notes about HTTP/3
41–50 of 181 posts
Re: Some notes about HTTP/3
#42Earlier quoted context omitted.
I'm curious, how does SCTP tunneled over UDP compare to QUIC? https://tools.ietf.org/html/rfc6951
It compares in the way that there's not a single SCTP web server implementation compared to QUIC. People here say that we should use HTTP/2 over SCTP, no protocol will be adopted if there's no good implementations of it.
Re: Some notes about HTTP/3
#43Earlier quoted context omitted.
Not unless you want to get through firewalls seamlessly. UDP "state" tracking is a thing, and if my firewall sees a UDP packet destined for it without knowing the remote IP address it's going to drop it.
Which is yet another reason to migrate to IPv6, which doesn’t require stateful NAT.
Re: Some notes about HTTP/3
#44Earlier quoted context omitted.
Those do not affect TCP state machine parameters like RTO(min), ATO, and TLP timeout. These are internal to the kernel and are either static, or can only be set systemwide. For example the minimum delayed ack timeout in Linux is just 40ms and can't be changed except by recompiling the kernel. 40ms is a totally inappropriate number for ATO in a datacenter or other low-latency setting. Other numbers like RTO(min) are s…
Again, as someone who does not completely grok QUIC I am not dismissing it. I was hoping if some parameters were not exposed work would be put toward making these available through existing interfaces.
Notably many of the people whose proposals have been shot down by linux netdev are currently working on QUIC.
Re: Some notes about HTTP/3
#45Most of the deadliest DDoS attacks happen over UDP. Spoofing, reflection and amplification just to name a few. Many businesses just deny UDP to protect themself against the on going DDoS threats. I feel this move won't make internet a better and safer place, but let's see.
QUIC uses two mechanism to make sure you cannot do such attacks:
* it requires a proof of IP ownership (exactly like TCP sequence numbers) to setup a connection ID (pretty much, you're able to receive the server's response to finalize the connection) [1]
* it requires the client's first message (client hello) to be padded to at least the size of the server's response. Which implies that an attacker would require as much bandwidth as is spent by the server performing the attack, making the attack as practical as the attack without QUIC. [2]
[1]: https://tools.ietf.org/html/draft-ietf-quic-transport-16#sec...
[2]: https://tools.ietf.org/html/draft-ietf-quic-tls-16#section-9...
Re: Some notes about HTTP/3
#46Re: Some notes about HTTP/3
#47I feel like the adoption of HTTP/3 is going to be much much slower than HTTP/2... Besides Google Cloud do any of the major cloud providers have UDP load balancers?
On the other hand, HTTP/3 is way, way faster. So there are strong incentives for big players to adopt it as fast as possible :)
Re: Some notes about HTTP/3
#48The IETF is not a conventional SDO, nor indeed a conventional organisation of any sort, since it has no members, and it operates on "rough consensus" rather than having some specific formal process that invariably (see Microsoft's interaction with ECMA and ISO) would be gamed by scumbags.
But nevertheless those are de jure standards that come out the far end, the result of "getting all major stakeholders in a room" albeit that room is most often a mailing list since only a hardcore few can attend every IETF physical meeting. The IETF even explicitly marks standards track RFCs distinctly from non-standards track ones. If you contribute documentation for a complete working system, rather than (as Google did with QUIC) a proposal based on such a system that needs further refinement, it'll just get published as an Informational RFC. Such RFCs are how a bunch of Microsoft network protocols are documented, by Microsoft. Whereas months of arguing and back-and-forth technical discussion have shaped the IETF's QUIC and will continue to do so, the documentation for MSCHAPv2 (commonly used in corporate WiFi deployments) is an informational RFC so a Microsoft employee just dumped it as written, no chance for anyone to say "Er, this protocol is stupid, change it not to shove zero bytes into this key labelled C or else anybody can crack user passwords after spoofing the AP". So they didn't, and you can.
[Edited: wording tweaks near start, sorry]