Subject: [quicwg/base-drafts] HTTP/3 Client handling of SERVER_BUSY error code needs to be specified (#2699)

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 14 May 2019 14:51:59 -0700

The transport draft defines the SERVER_BUSY error code. It is suggested that this error code be sent when the server cannot process new connections for example when it is under DoS attack or wants to take down the QUIC endpoint for servicing. The HTTP/3 draft should specify how a client should handle this error. IMO the client in this case should fallback to HTTP/2. 

-- 
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/2699

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 14 May 2019 14:58:26 -0700

Isn't this already covered under generic concept of alt-svc or TCP fallback?

IMO stating a fallback to a specific version of HTTP is not the correct recommendation. 

-- 
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/2699#issuecomment-492425574

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 14 May 2019 15:04:16 -0700

Which generic concept? I don't see any mention of when the fallback should be done in the HTTP/3 spec. Why would recommending fallback to previous version of HTTP not be the correct recommendation? We clearly need some way of handling SERVER_BUSY on the client side. I don't think we should leave it unspecified.

-- 
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/2699#issuecomment-492427225

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 14 May 2019 15:30:16 -0700

Since alt-svc is the only discovery mechanism defined for HTTP/3. Failure of the alternative (for whatever reason) should mean that the alt-svc entry is removed from the alt-svc cache and the UA returns to the original authority that advertised the now-failed alternative. Note that alt-svc could be chained, so specificying any particular fallback behaviour risks conflicting guidance for how UAs should behave.

-- 
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/2699#issuecomment-492434443

---

From: Nick Banks <[email-masked]>
Date: Wed, 15 May 2019 02:15:06 -0700

We can't tie this to Alt-Svc completely. The load balancer / DoS mitigation infrastructure will need to make decisions on the fly; independent of the back end QUIC servers (which might not even be HTTP/3) and temporarily block new connections to the QUIC servers. The HTTP/2 TCP servers won't even necessarily know of the change. When the infrastructure does this, we need to make sure clients know to fallback to TCP.

-- 
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/2699#issuecomment-492574442

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 15 May 2019 02:24:06 -0700

So consider this chain:

example.com (HTTP/2) -> example.org (HTTP/3)
example.org (HTTP/3) -> alt.example.org (HTTP/3)

If alt.examples.org fails, it is valid to fallback to example.org and use QUIC. If you specify a fallback to TCP, where would you expect the client to go back to? The client has no authoritative information that declarers example.org can handle TCP.

-- 
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/2699#issuecomment-492577470

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 15 May 2019 10:30:46 -0700

Yeah I don't think we  want to revoke the service here. We may want to keep a selective portion of high value traffic active. In the DoS case for example there could be additional signals determining which IP prefixes to reject immediately. 

In the chain example if there is no possible fallback the client should simply stop connecting for a while maybe using exponential backoff.

-- 
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/2699#issuecomment-492748829

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 15 May 2019 10:44:31 -0700

I believe Chrome have some behaviour like that. It isn't codified into the specs but I'm sure there is some good practice out there we can learn from.

For instance, fallback from a HTTP level error (I.e. a 500) was discussed on the HTTPbis mailing list in the last year.

-- 
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/2699#issuecomment-492754041

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 15 May 2019 11:48:22 -0700

Yeah Chrome does. I think we should have recommendations about fallback in the spec so we don't end up with wildly different client behaviors making server side and infrastructure behavior complicated. I'd at least consider adding text around QUIC connection failures, GOAWAY and SERVER_BUSY handling and any other transport protocol errors. I think there is reasonable coverage for HTTP/3 errors.

-- 
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/2699#issuecomment-492777701

---

From: ianswett <[email-masked]>
Date: Wed, 15 May 2019 11:53:26 -0700

I'd support adding some text on what we think best practices are for those cases.  It may be worth separating handshake failures and post-handshake connection failures?

-- 
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/2699#issuecomment-492779537

---

From: ianswett <[email-masked]>
Date: Wed, 15 May 2019 11:54:19 -0700

Yes, Chrome immediately falls back anytime the handshake fails for any reason.  Which makes sense, given the alternative is to have the request fail.

-- 
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/2699#issuecomment-492779919

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 15 May 2019 18:55:20 +0000 (UTC)

Well GOAWAY is fairly broke in HTTP/2 right now anyway 😃

I think guidance is useful, I'm not convinced the HTTP/3 document is the correct place to capture that. 

-- 
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/2699#issuecomment-492780278

---

From: Udip Pant <[email-masked]>
Date: Thu, 23 May 2019 06:10:49 -0700

Based on the text (https://tools.ietf.org/html/draft-ietf-quic-transport-20#section-5.2.2), my interpretation is that the server can respond with SERVER_BUSY (only) when it receives Initial packet from the client (i.e. during/pre handshake). So any client with implementation of happyeyeball-like race mechanism between QUIC and TCP should fallback to TCP.

Post handshake, the server can either send GO_AWAY or stateless reset depending on the application protocol and circumstances, and client can try to re-establish QUIC connection.

Since this issue is not HTTP3 specific, I agree with @LPardue that HTTP3 is probably not the right place. (Also, what else could client do in this case anyway?). As @ianswett mentioned above, clarifying this in the quic-transport spec would be helpful.

-- 
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/2699#issuecomment-495211676

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 23 May 2019 09:27:05 -0700

"So any client with implementation of happyeyeball-like race mechanism between QUIC and TCP should fallback to TCP."
AFAICT this race mechanism isn't described anywhere in H3. Some implementations may choose to not always race and cache the server response per session and if H3 succeeds then continue doing just H3.  IMO therefore we need additional text suggesting that the client stop retrying QUIC for a period or use exponential backoff and fallback to H2 when it receives SERVER_BUSY. 

-- 
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/2699#issuecomment-495290018

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 23 May 2019 10:33:47 -0700

Still disagree. As Mark highlighted in the inteeim session, the collection of HTTP documents already has a lot of existing language around the problem of how a endpoints can react to lower layer errors.

Recommending any specific behavior for H3 just complicates the overall narrative. 

Perhaps there is space for a more general description, like a BCP, in a separate document that applies to the HTTP semantic. 

-- 
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/2699#issuecomment-495313038