- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 11 Jul 2014 11:30:37 -0700
- To: Willy Tarreau <w@1wt.eu>
- Cc: Greg Wilkins <gregw@intalio.com>, Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 11 July 2014 11:08, Willy Tarreau <w@1wt.eu> wrote: > I think that in Roberto's case, it's the opposite in fact. Assuming he > runs a customer-facing gateway that aggregates streams to origin servers > using less connections, *and* that he forwards headers on the fly without > buffering, then a slow client sending a small header frame and slowly > pushing continuation frames would simply block all traffic from all other > clients to that same server for the same connection. That's true. So don't do that. Perhaps we are talking past each other. Here's the matrix: 0 can and do stream (1-3), no need for max_size frames (!4), no interleaving (!5) - No state commitment DoS concern - May spend extra cycles on framing - May have HOL - No stalling 1 can and do stream (1-3), need to fill frames before CONTINUATION (4), no interleaving (!5) - No state commitment DoS concern - No extra cycles on unnecessary framing - May have HOL - May stall 2 don't stream, no need for max_size frames (!4), no interleaving (!5) - This is the status quo - No state commitment DoS concern - May spend extra cycles on framing - May have HOL - No stalling 3 don't stream, need to fill frames before CONTINUATION (4), no interleaving (!5) - No state commitment DoS concern - No extra cycles on unnecessary framing - May have HOL - May stall 4 can and do stream (1-3), no need for max_size frames (!4), interleaving (5) - No state commitment DoS concern - May spend extra cycles on framing - Can avoid HOL - May stall 5 can and do stream (1-3), need to fill frames before CONTINUATION (4), interleaving (5) - State commitment DoS concern - No extra cycles on unnecessary framing - No HOL - May stall - Streaming not possible where max_size doesn't match up 6 don't stream, no need for max_size frames (!4), interleaving (5) - State commitment DoS concern - May spend extra cycles on framing - Can avoid HOL - No stalling 7 don't stream, need to fill frames before CONTINUATION (4), interleaving (5) - State commitment DoS concern - No extra cycles on unnecessary framing - Can avoid HOL - May stall I think that's good enough for our purposes. Given that my priority order here is approximately: state commitment > stalling > HOL > CPU, I think that status quo is looking pretty good. Note that option 5, which is the complete combination of all proposed changes, seems to actually be the worst in this analysis.
Received on Friday, 11 July 2014 18:31:09 UTC