Re: Striving for Compromise (Consensus?)

Hi Martin,

sorry, it took me a while to understand how to read your matrix,
but this morning the coffee helped me :-)

I have a comment below.

On Fri, Jul 11, 2014 at 11:30:37AM -0700, 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:
> 
> 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.

Option 5 allows agents with smaller buffers to reject CONTINUATION frames,
which removes state commitment and DoS concern. It seems to be the closest
to the situation we have in 1.1 where a message that does not fit in the
recipient's buffers is simply rejected (eg: 400 or 502).

Option 2 becomes better when you enable max_frame_size since it removes
the "May have HOL".

Best regards,
Willy

Received on Sunday, 13 July 2014 05:35:36 UTC