101–110 of 246 posts
if we could magically do not care about compatibility how we could redesign/rewrite internet now in order to make it better? what could've been done better? how better performance could be?
Earlier quoted context omitted.
i think the intent is that normally you would do a lot of syscalls in order to do networking; with QUICK you would currently be forced to do do zero-copy networking and pass the frames to the kernal via pf-ring; things don't become simpler, as the network layers will have to be handled by a user mode library, however they would potentially be much faster.
> forced ?? why shouldn't quick be able to use a udp socket?
Earlier quoted context omitted.
I assume you're referring to the disuse of SCTP? That's not because of ossification, it's because of middleware boxes like NATs and firewalls that will refuse to pass anything that isn't TCP, UDP, or ICMP.
Which is an example of ossification, in this case at the IP level.
Earlier quoted context omitted.
> Have previous protocols (TCP, UDP, etc) been in widespread use before their respective RFCs? As other people have noted, yes. One of the interesting facts about the IETF is that they actually require two existing implementations in order to advance from an RFC to an official "Internet Standard": The IETF Standards Process (RFC 2026, updated by RFC 6410) requires at least two independent and inter-operable implement…
There are less than 100 Internet Standards ( https://www.rfc-editor.org/standards ).
> The internet transport ecosystem has been ossified for decades now, and QUIC breaks out of this ossification But it's still just a layer on top of UDP, and still implemented at the application, like in the past. So how is the ossification broken? Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a…
It has to do with the distinction that middleware boxes make between layer 4 and layer 5. NATs and firewalls and assorted traffic optimizers tend to vomit if you pass anything over IP that isn't TCP, UDP, or ICMP.
UDP is, by luck and design, a very thin shim on top of which a "layer 4.5" protocol is very easy to implement. Whether this layering is done in the kernel or in a userspace library is an implementation detail, and one that will probably be obscured even from many userspace programs.
Is it possible to compile quicly cli (referenced in the blog post) with musl instead of glibc. I had to add signal.h and it then compiled successfully (using openssl-1.1k) but I got illegal instruction core dumped when executing cli. https://github.com/h2o/quicly There are a few Rust alternatives for QUIC. Anyone tried them and have comments. https://github.com/cloudflare/quiche https://github.com/quinn-rs/quinn http…
Maybe QUIC would also mean the CPU working harder, but I'm not really sure.
I would be nice to have a thoughtful conversation about the security implication of QUIC: Wikipedia says packets are encrypted individually.
I'm also curious: is QUIC exclusively aimed towards HTTP2 or can it be used for real time applications, like real time gaming or video conferencing?
I am still wondering, isn't TCP hardware accelerated? Maybe QUIC would also mean the CPU working harder, but I'm not really sure. I would be nice to have a thoughtful conversation about the security implication of QUIC: Wikipedia says packets are encrypted individually. I'm also curious: is QUIC exclusively aimed towards HTTP2 or can it be used for real time applications, like real time gaming or video conferencing?
Google is not Requesting For Comments at all. It is imposing its things. Despite the fancy number, this is not an RFC at all, in the ancient sense of the acronym, nor it has the same design principles of simplicity and orthogonality.
I have spoken with Daniel Stenberg about this and if I recall correctly he disagreed and said that the QUIC which ended up being standardized is quite different from Google's QUIC.
Earlier quoted context omitted.
They wanted a protocol as opaque to middleboxes as possible. SCTP probably isn't, that was not an issue back when it was created.
What Google wants for itself should be irrelevant to the broader Inter-Network standards.
Google owns the Internet.