<discocaml>
<joris0588> > for other things, if you don't use tcp you end up having to reinvent it badly
<discocaml>
<joris0588> i guess that is debatable. On one hand, yes. But in a lot of cases, tcp is too strong/has limitations.
<discocaml>
<joris0588> in particular, it is single flow. So you have two create multiple connections to provide the same ordering garrantees, which is not always tractable, this is in part how we end up with QUIC and framing/flows with a single tls layer.
<discocaml>
<joris0588> the other issues that comes to bite related to framing is that, by implementing framing on top of tcp stream, with tcp acting as a transport, tcp lacks visibility in the application level
<discocaml>
<joris0588> which means, a single loss can affect/multiple messages, as the reliability layer is at the transport level. Which makes it less resilient to failure if you don't need total ordering for your messages
<discocaml>
<joris0588> in the end i would argue in 2024 QUIC is simply a better "use this by default" protocol than tcp, and it builds on tcp legacy/strength. Quality of implementation, especially in flow/congestion control vary badly though
<discocaml>
<joris0588> this does not help that this is optional in the spec (afaik ocaml-quic does not implement anything in this area)
<companion_cube>
oh a wild joris appears
<discocaml>
<joris0588> 🙂
<discocaml>
<hannes6838> I don't quite understand, is this an opinion for "all network connections"? or rather something for "datacenter connections" (i.e. somewhere where you've other problems if packets are getting lost or being delayed or so? Would a "always use QUIC" be true if you're on a LTE uplink or on a very poor uplink (low bandwidth, lossy connection)?
<companion_cube>
I also thought http3 made more sense for clients, but not really between machines in a data center, where TCP is reliable enough?
<companion_cube>
(at my little scale anyway, idk)
<discocaml>
<joris0588> yeah i am obviously biased to some specific area. I have no idea about LTE things, i was answering in term of game dev but my opinion is obviously biased to distributed system impelementations
<discocaml>
<joris0588> though, inside a datacenter packet loss is usually not a problem because network there has become so so so so reliable, you just don't lose packet, at latency is in microseconds
<discocaml>
<joris0588> > but not really between machines in a data center, where TCP is reliable enough?
<discocaml>
<joris0588> that is true inside a datacenter. That is not true if you have several datacenters around the world.
<discocaml>
<joris0588> but in my opinion, the great strength of quic is that you have flows. So you can multiplex several flows inside a single connection, and this shines when you have congestion and loss. Because you can send messages independantly, and ensure they error are contained to a single flow/session. Especially true with message passing/RPC
<discocaml>
<joris0588> i mean, if you use tcp, and you send several multiplexed message from A to B, and there is an error. Error will affect/delay all of your messages, because you need to process them in order
<companion_cube>
right, I have a hard time imagining writing software doing time critical RPCs _across_ data centers 😅
<discocaml>
<joris0588> with messages at the protocol level, this is not necessarily true (again depend on the implementation)
<discocaml>
<joris0588> the other advantage is why quic was developed for web stuffs. Flow control by application stream. Like you load a webpages, it has CSS, images, etc. If you send all requests through a couple of tcp stream, and bandwidth is limited, you don't have control over stuffs like "i need css to render the page, but image can wait"
<discocaml>
<joris0588> with multiple flows with independant flow control, you can ensure that CSS loads while images don't starve for bandwidth
<discocaml>
<joris0588> this is also true for message passing in practice. And again this can be done by launching many tcp connections, but it is not always possible (you might run out of ports in the server, or you will have to pay for handshake several times...)
<companion_cube>
you could also put them in the right order, but anyway
<companion_cube>
the browser does open multiple connections, for reasonable pages it should be enough
<companion_cube>
(reasonable = doesn't load 100s of things)
<companion_cube>
quic seems pretty nice but it's not going to always work either since it's UDP :/
<discocaml>
<joris0588> why not ? you mean because of really old routers stuffs ?
<companion_cube>
sure, all the infra that blocks UDP
<companion_cube>
maybe they'll open it on the https port, idk
<discocaml>
<joris0588> is there any infra that block udp ? i mean dns... But yeah the worst i saw is stupid old router that tend to treat udp as low priority in their qos, and the bigger problem, routers that thing that udp is message based and not part of a connection, so they do multipath routing, which is a pain with reodering packets
<discocaml>
<joris0588> @companion_cube honnestly though, quic is picking up steam, and google is throwing all its weight behind it
<discocaml>
<joris0588> just as an example, right now at work, more than 50% of requests are HTTP/3, this is quite a lot
<discocaml>
<joris0588> pretty sure the internet can handle it
<discocaml>
<joris0588> cloudflare also supports dns over http/3 for like 2 years, this is avaible on android... The protocol is really first class by now
euphores has joined #ocaml
toastal has left #ocaml [Error from remote client]
<discocaml>
<leostera> i use fzf in neovim! works like a charm ✨
dawids_ has quit [Quit: Leaving]
<discocaml>
<barconstruction> Are there benchmarks available of OCaml against various implementations of Standard ML? Probably MLton is faster than OCaml, with the usual tradeoffs of not having incremental separate compilation, but I'd like to see how much it matters in practice.
bartholin has quit [Quit: Leaving]
<companion_cube>
I remember not having many udp ports at school
<companion_cube>
Anyway I'd bind a library to ocaml, rather than reimplement the thing
<discocaml>
<joris0588> yeah but, binding async io is notoriously hard. You better luck to have a very clean implementation
<companion_cube>
Isn't there a sans-io implem?
<companion_cube>
I mean you can also just use curl, I think it supports http3 optionally
<discocaml>
<joris0588> yeah probably curl is a good bet
<discocaml>
<joris0588> i mean, my SRE trick solution to all of that, is a hack
<discocaml>
<joris0588> use http/1.1 on localhost and proxy that to something that has a good quic implementation. duh. no binding required 😄
<discocaml>
<joris0588> (and this is how, you end up with k8s mess, famous last word. or you know, using ebpf to introspect network traffic for observability)
<companion_cube>
I mean that's standard no? :)
<companion_cube>
I don't serve TLS or http2, I let nginx or whatever do it for me