4 ms·
I wonder if the trick might be to repurpose technology from server hardware: partition the physical NIC into virtual PCI-e devices with distinct addresses, and
by jiggawatts 2y ago
I wonder if the trick might be to repurpose technology from server hardware: partition the physical NIC into virtual PCI-e devices with distinct addresses, and map to user-space processes instead of virtual machines.
So in essence, each browser tab or even each listening UDP socket could have a distinct IPv6 address dedicated to it, with packets delivered into a ring buffer in user-mode. This is so similar to what goes on with hypervisors now that existing hardware designs might even be able to handle it already.
Just an idle thought...
- KaiserPro 2y agoOr just have multiple TCP streams. Super simple, low cost, uses all the optimisations we have already. when the latency/packet drop is low, prune the connections and you get monster speed. When the latency/loss is high, grow the number of concurrent connections to overcome slow start. Doesn't give you QUIC like multipath though.
- m_eiman 2y agoThere’s Multipath TCP.
- KaiserPro 2y agoI mean there is, but from what I recall its more a link aggregation thing, rather than a network portable system
- gmokki 2y agoIt seems to support failover smoothly over various links. Interesting article about combining starlinks, 4G + 5G to single mptcp that works on the move: https://dillonbaird.io/articles/mptcpbonding/ https://dillonbaird.io/articles/mptcpbonding/
- jeroenhd 2y agoI've often pondered if it was possible to assign every application/tab/domain/origin a different IPv6 address to exchange data with, to make tracking people just a tad harder, but also to simplify per-process firewall rules. With the bare minimum, a /64, you could easily host billions of addresses per device without running out. I think there may be a limit to how many IP addresses NICs (and maybe drivers) can track at once, though. What I don't really get is why QUIC had to be invented when multi-stream protocols like SCTP already exist. SCTP brings the reliability of TCP with the multi-stream system that makes QUIC good for websites. Piping TLS over it is a bit of a pain (you don't want a separate handshake per stream), but surely there could be techniques to make it less painful (leveraging 0-RTT? Using session resumptions with tickets from the first connected stream?).
- simiones 2y agoFirst and foremost, you can't use SCTP on the Internet, so the whole idea is dead on arrival. The Internet only really works for TCP and UDP over IP - anything else, you have a loooooong tail of networks which will drop the traffic. Secondly, the whole point of QUIC is to merge the TLS and transport handskakes into a single packet, to reduce RTT. This would mean you need to modify SCTP anyway to allow for this use case, so even what small support exists for SCTP in the large would need to be upgraded. Thirdly, there is no reason to think that SCTP is better handled than UDP at the kernel's IP stack level. All of the problems of memory optimizations are likely to be much worse for SCTP than for UDP, as it's used far, far less.
- astrange 2y agoIs there a service like test-ipv6 to see if SCTP works? Obviously harder to run since you can't do it in a browser.
- simiones 2y agoI doubt there is, because it's just not a very popular thing to even try. Even WebRTC, which uses SCTP for non-streaming data channels, uses it over DTLS over UDP.