Re: Striving for Compromise (Consensus?)

On 12/07/2014 6:30 a.m., Martin Thomson wrote:
> 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:

Greg Wrote:
> 
> 1) Increase frame size to 16-bits
> 1a) Add a settings for max_frame_size
> 2) Remove reference set from HPACK allowing for "streaming" decoding.
> 3) Requiring that all ":"-headers appear first.
> 4) Only allowing CONTINUATION if the previous frame is max_frame_size.
> 5) Allowing interleaving of CONTINUATION frames with other frames.
> 5b) The size of the HEADERS and CONTINUATION frames are removed from the
> flow control window, but the they are never flow controlled.
> 
> 
> 


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

Strange that Roberto's argument for keeping status-quo was that we need
it to stream headers. But you summarize status-quo under "don't stream".
I find that case (0) above is closer to 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.
> 


Matrix case (2) has more in common with "Greg et al" large frames
proposal than status-quo h2-13.
 * dont stream (large frames requests buffering on sender)
 * no need for max_size frames (large frames sends frame size matching
payload)
 * no interleaving (Greg et al large frames does not permit even
mistaken implementers to accidentally interleave frames inside each
others payload)

Greg et al proposal causes the '-' bullets to change thusly:

 - "No state commitment DoS concern" - Greg et al frame limit removes
implementations protocol mandated commitment to handle infinite-length
CONTINUATION payload. Greatlyimproving this over the status-quo.

 - "May spend extra cycles on framing" - Greg et al frames remove this
issue completely.

 - "May have HOL" - no change here, but Greg et al frames permit senders
to mediate frame size and prevent HOL blocking on outgoing connections.
status-quo actually mandates buffering "state commitment DoS concern" as
the only possible way to resolve HOL blocking.

 - "No stalling" - stalling is *always* possible with frames overhead
about 3 bytes. It is a TCP behaviour. h2 has frame overhead 8-12 bytes.



As for your priority order:

> Given that my priority order here is approximately:

> state commitment >

Greg et al. large frames leave the state commitmet equal to status quo
unless implementer decides otherwise. Implemeter may advertise *less*
state commitment than h2 specification default.

> stalling

Stalling is possible in all circumstances where more than two bytes need
to be strung together. status quo is *very bad* in encouraging this, as
are the interleaving and fragmentation proposals.

Greg et al large frames require the sender to accumulate the frame
before delivery to ensure length is accurate. This actively closes many
paths and potential HTTP/2 implementation mistakes leading to stalling.
The remaining causes are all TCP induced and need to be resolved at the
TCP layer.

> HOL

Only occurs with status quo and proposals involving CONTINUATION or
fragments.
Greg et al large frames constrains senders not to send at all unless the
frame is fully available and can be delivered.


> CPU, I think that status quo is looking pretty good.

I think that Greg et al frames proposal still looks better.

Amos

Received on Saturday, 12 July 2014 03:34:30 UTC