search

ietf-wg-masque / draft-ietf-masque-quic-proxy

Other
12 stars 7 forks source link

QUIC-LB and proxies #54

Closed martinduke closed 1 year ago

martinduke commented 2 years ago

Thanks for considering the implications of QUIC-LB in this draft.

Your recommendation might be too draconian. Note that QUIC-LB only adds value in case of address migration. I see a few different solutions depending on use case if the proxies have to be load balanced:

  1. If proxy and server can coordinate, multiple tier LBs are already addressed in the quic-lb draft; clear sailing here, as you've written

  2. The proxy can simply send disable-migration and then use 4-tuple load balancing. Then the CID doesn't matter to the proxy. In this case the client MUST not change the destination CID in forwarded packets. If it needs to migrate, it can open a new 0RTT connection to the proxy and can even use the same inner connection.

Unfortunately, this breaks migration for tunneled connections in these deployments as well.

  1. There could be a "proxy-behind-lb" response header. If present, and the client must migrate, all subsequent client packets MUST use tunneled mode until one of them is acked. The proxy LB is 4-tuple based if it has observed the 4-tuple before; otherwise, it uses the CID (i.e. it assumes the packet is tunnel mode). I suspect most Quic-LB devices will keep 4-tuple state in this manner anyway, though it isn't required.

The idea here is that the tunneled packets allow the LB to learn to associate the 4 tuple with the correct proxy, informed by the outer CID, before reverting to forwarding mode.

tfpauly commented 1 year ago

60 and #62 added virtual CID support in the proxy, which should address support for QUIC-LB. @martinduke please a file a new issue if you see more that would need to be done!

martinduke commented 1 year ago

Yes, this is a clever solution to the core issue. I will file a new issue for further complaints.