Re: [quicwg/base-drafts] How to reject a connection attempt (#3690)

[Kazuho Oku <[e-mail]>]

> HTTP has 503 to reject request when a server is busy, and still we have SERVER_BUSY at the QUIC layer. There's a value in rejecting connection attempts before spending resources (and round trips) on a handshake.

Yes, TCP or TLS can reject one attempt. QUIC is currently aligned to that, and that's fine.

> Furthermore, there are other application protocols than HTTP. In my use case, nodes in a p2p network want to enforce a local blacklist of IP addresses. In TCP, they can easily do that by resetting the connection, and before spending any resources on the TLS handshake. Having to go through the whole QUIC handshake with a blacklisted peer before being able to reject them would be a serious regression compared to TCP.

I'd point out that how aggressively browsers try connecting in QUIC depends on if they do happy-eyeballing. When browsers do happy-eyeballing, no matter how less you do in QUIC, the probability of establishing a connection always stays higher (or as high as) just doing TLS.

The question is when browsers start doing just QUIC. Would they prefer to cache previous connection failures, as a way to not even try to reconnect when a user requests doing so?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3690#issuecomment-633226437