quiche

Yeah, my naive implementation thought experiment was oriented towards a side channel brokered by the ssh connection using nginx and curl. Something like source opens nginx to share a file and tells sink via ssh to curl the file from source with a particular cert. However, I observed that curl [0] uses openssl' quic implementation (for one of its experimental implementations). Another backend for curl is Quiche [1] which has client and server components already, has the userspace crypto etc. It's a little confusing to me, but CloudFlare also has a project quiche [2] which is a Rust crate with a CLI to share and consume files. 0. https://curl.se/docs/http3.html 1. https://github.com/google/quiche/tree/main/quiche/quic 2. https://github.com/cloudflare/quiche

> If you balance your load balancers with ECMP, I don't know if you can get two client streams to the same mptcp terminating place. At Google, we do something similar with QUIC and connection migration. Our mechanism for ensuring these hit the same backend is Maglev [0], where we use the QUIC connection ID for hashing purposes in software. (Our routers still mostly use ECMP based on the 5-tuple, so being able to consistently hash to the same backend across multiple LB instances is crucial.) > if a path segment has high loss/corruption or is congested, MPTCP could help if you had an extra connection that hit a different path. Incidentally, we also have a family of internal mechanisms that do this, although we don't rely on MPTCP. (We instead twiddle some other bits in the packet that we make sure our routers use for hashing, at least for R

We followed the same spec on the Google side (obviously). Our implementation of the request encapsulation/decapsulation for OHTTP is open sourced in Google Quiche. https://github.com/google/quiche/tree/main/quiche/oblivious_...