Expected Client Response to SERVER_BUSY

[Nick Banks <[e-mail]>]

Hello Folks,

I've been looking at interim DDoS mitigation strategies for QUIC until we can have a more complete and QUIC aware DDoS and LB solution. One thing I came up with is just trying to force the client to fallback to TCP. Eventually, we will use Stateless Retry but that still requires a good bit of design work and cooperation between the offload device and the backend server. Until that is complete, a simple solution could be a device in path just responding to new QUIC connection attempts (while an attack is in progress) with a connection close frame containing the SERVER_BUSY error. The logic to implement a simple device to do that should be quite trivial.

To that end, I was trying to figure out what the expected client response to any immediate (in the first RTT) connection close packets/frames would be and it seems we don't have anything in the spec. What about SERVER_BUSY specifically? Is the client supposed to retry a new connection attempt? Should they fallback to TCP immediately? Should we say anything in the spec?

Thanks,
- Nick