91–100 of 246 posts
Earlier quoted context omitted.
because of the ossification that makes it hard/impossible to use.
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.
Earlier quoted context omitted.
I think from their perspective the (Windows and Android) kernel is what causes ossification so moving transport into the app, along with encryption, solves it.
You're forgetting the rest of userspace that exists between the application and the kernel. > moving transport into the app, along with encryption, solves it This is only a good idea if the application's development moves faster than both the kernel and the rest of the userspace platform - which is a fine strategy if you're targeting old or obsolete platforms, but probably a bad idea if you're targeting currently-sup…
> 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…
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.
?? why shouldn't quick be able to use a udp socket?
Earlier quoted context omitted.
I use OpenMPTCPRouter [1]. It's a bit of kitchen sink so I'm thinking of replacing it with something simpler, but the basic idea is that you have a TCP->MPTCP converter running on your router and MPTCP->TCP converter running on some cloud instance. [1] https://www.openmptcprouter.com/
Wouldn't QUIC work all the same with that setup, considering that you're not using MPTCP end-to-end? Or do you have a SOCKS or HTTP proxy on the other side of the aggregated links? Also, why do you need MPTCP for this? Aren't there simpler methods for this kind of setup, like LACP? Or is OpenMPTCProuter, like OpenVPN, one of those things that everybody uses because everybody else does, with more informal documentatio…
The problem OpenMPTCPRouter solves is this: you do
curl -O https://somewhere.example.com/largefile.tar.gz
(just a single TCP flow) with 3x50Mbps LTE links, or, better, 80Gbps+40Gbps+30Gbps links and you get a bit less than 150Mbps download speed.
LACP doesn't solve it at all for several reasons.
1) LACP assigns each flow to a single network interface so as to avoid packet reordering
2) Even if you use other bonding mode that can spread the flows over several network interfaces, you'll get low throughput due to the aforementioned reordering and also due to the congestion control, more on that below.
Bonding works well when you have several "equal" links, which is not the case with LTE, where the speed may be quite different across the links and also vary with time.
Last but far from least, there is congestion control mechanism which is present both in QUIC and (MP)TCP, which makes sure the transfer is as fast as possible without harming other connections on the same link(s). This mechanism as it is used in QUIC and plain TCP is not very good at handling multiple aggregated unequal links, so no matter which way you do the aggregation on L2 (bonding) or L3 (things like glorytun), the performance is going to be suboptimal.
What MPTCP does is establishing a separate subflow (think TCP subconnection) for each of the available paths, with its own separate congestion control, and spreading the main flow over multiple subflows byte-by-byte in an optimal way. This gives maximum possible utilization of all of the available links, and prevents the congestion in an optimal way, too.
Earlier quoted context omitted.
Sorry for incorrect wording. I don't need multipath to be present in the same spec as the QUIC core. What I meant is when I will be able to have slightly less then 150Mbps over QUIC for e.g. a single file if I have 3x50Mbps connections. MPTCP can do that for me, even if the server doesn't support it as I can use something like OpenMPTCPRouter [1]. I hope multipath QUIC will be able to do that too, but it's not ready…
Seems like there are quite a few options that show up pretty quickly when searching for multipath udp e.g: https://github.com/angt/glorytun Would that work for you?
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.
Earlier quoted context omitted.
> 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 lot of extra work). Which also increases context switching Nowhere does RFC9000 say that it has to be implemented in user-space. A kernel-space implementation of QUIC would be conforming. Any OS kernel project (whether open source or proprietary)…
And why does it have to be handled in the OS, if a library would do just fine and provide more flexibility?
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.
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.
Very much like HTTP 2/3, it solves primarily Google's problems.
Earlier quoted context omitted.
I would start by: - 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/Ed25…
Well, I expected more radical/foundational changes than "upgrade to $modern standards" :P e.g change TCP to $YOLO PROTOCOL, get rid of OSI for something different