71–80 of 246 posts
Should have waited for 9001. Oh my mistake, they have several RFCs from 8999-9002.
Sure, and that's one good meme. But we also get to make some HAL 9000 jokes about Google now, and that's even better (though ironic, given that it was intended to be IBM jokes).
Wake me up when multipath support is included... Till then I prefer TCP b/c I can use MPTCP to utilize all of my rural LTE bandwidth for each single flow (e.g. downloading a file)
SCTP would have been great for all sorts of applications other than QUIC too. It's got built in multihoming for seamless handoff in mobile environments to keep a persistent connection across e.g. WiFi and cellular. Want multiple streams with no HoL blocking? SCTP is message based and can deliver multiple "streams" simultaneously over a single connection and you get free message boundaries to boot instead of just a plain stream like TCP. Want unordered datagrams? It's got that too. Even partial reliability for a subset of messages in a connection, i.e. reliable metadata for an unreliable live low latency video stream. The four way handshake also basically eliminates the potential impact of a SYN flood.
Wake me up when multipath support is included... Till then I prefer TCP b/c I can use MPTCP to utilize all of my rural LTE bandwidth for each single flow (e.g. downloading a file)
I just really wish Google would have built QUIC on top of SCTP. They had the clout, and opportunity to push for real end-to-end SCTP support across the internet. Tunnel it over UDP for IPv4 and userspace implementations but use native SCTP where possible like over IPv6 before middleboxes abound that only support TCP, UDP, and ICMP. There's too many NAT implementations, firewalls, etc that don't support SCTP on IPv4 b…
I wish the QUIC design was datagram-first... so many client/server implementations don't implement the datagram extension properly because it's... well an extension, and for most applications, reliable sequencing should be eschewed in favor of client-side reassembly. IMO QUIC was far too influenced by the legacy of how HTTP works when there was an opportunity to leapfrog a generation of bad decisions.
I'm genuinely interested in what aspects you think are (or were) not implemented properly.
I wrote most of the implementation of quiche's datagram extension and, well, if there's something that can be improved, I'm all for it.
(aside: I think the standard should've considered an option for datagrams to opt-out of congestion control, given that most applications which want to take control over datagram sending probably also want to take control of available bandwidth and control congestion differently - e.g. by dropping encoding bitrate instead of queuing - but it is what it is).
how we could redesign/rewrite internet now in order to make it better?
what could've been done better?
how better performance could be?
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.
As far as orthogonality goes, it seems to be pretty orthogonal to different kind of uses, I'm not sure why you're saying it's not.
On simplicity it's definitely not simple, but given the problems it is trying to solve it's probably as simple as it could be.
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?
- Not allocating giant slices of IPv6/4 space to corporations or government agencies. Everything must be IPv6.
- Adding proper authentication to BGP.
- Taking off the super powers of CAs
- Not piling up standards on DNS.
- Killing ICANN because it turned out to be a greedy senseless organization.
- HTTPS is the standard, and email servers just follow the auth/encryption just like HTTPS.
- Curve/Ed25519 over P256/386 and RSA.
- TLS 1.3 is the standard, and remove all compromises made to keep the middle boxes happy.
- No PSL. Browser same-origin modal everywhere.