quic and http3 plans

[avrecko]

Do you have any plans to add quic and http3 support?

[apangin]

Yes, there are long-term plans for that, but it's unlikely that a production-ready solution will appear here in the nearest months.

[avrecko]

Makes perfect sense. Maybe just quic support would be interesting to see and how it would work for RPC server/client. Did you maybe already play around with quic support? V V pet., 5. avg. 2022 ob 13:44 je oseba Andrei Pangin < ***@***.***> napisala:

…

Yes, there are long-term plans for that, but it's unlikely that a production-ready solution will appear here in the nearest months. — Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRDOO726PRIEWGDJCHOLTVXT5CXANCNFSM55MJ3B4A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[apangin]

I'd say, RPC is NOT a good example for QUIC (if we talk about RPC in the context of communication between microservices).

QUIC is mostly beneficial for end user experience, especially when used over mobile and wireless networks. In a datacenter, where you have a high-bandwith wired connection, where a packet loss is rare, QUIC is just an unnecessary waste of resources. Basic TCP/TLS gives you higher throughput, while consuming much less CPU.

[apangin]

To extend my previous message: nearly all benefits of QUIC are useless in the RPC scenario:

• Zero RTT: not important, since a connection to another service is typically opened once and kept for the service lifetime.
• Multiplexing: not needed, as there is no problem in opening a large pool of connections.
• Head-of-line blocking: not relevant, parallel requests simply use different connections.
• Connection migration: not needed, there are no mobile <-> wi-fi transitions.
• Congestion control: makes much more sense for wireless networks.

[avrecko]

Great points, what about if the server and client are a bit far away - something like 300 ms rtt with slight packet loss? V V sob., 6. avg. 2022 ob 00:20 je oseba Andrei Pangin < ***@***.***> napisala:

…

To extend my previous message: nearly all benefits of QUIC are useless in the RPC scenario: - Zero RTT: not important, since a connection to another service is typically opened once and kept for the service lifetime. - Multiplexing: not needed, as there is no problem in opening a large pool of connections. - Head-of-line blocking: not relevant, parallel requests simply use different connections. - Connection migration: not needed, there are no mobile <-> wi-fi transitions. - Congestion control: makes much more sense for wireless networks. — Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRDOLRSFG3VR5OW7L2C2TVXWHUDANCNFSM55MJ3B4A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[apangin]

300 ms RTT is the opposite side of the globe. I just don't have experience of doing RPC in such configuration.