Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP

[Willy Tarreau <[e-mail]>]

Hi Pat,

On Fri, Mar 04, 2016 at 04:16:22PM -0500, Patrick McManus wrote:
(...)
> on the one hand, we've gone from the client having a high rate of  fast
> 0RTT fails (blocked from initiating by TW).. to a situation where 3 things
> are going on
> 
> 1] an unquantified "large" fraction of quick successes. (no packet loss
> impact, no state machine out of sync and no blockage by a timer)
> 2] a number of cases of fast 1RTT fail where a RST is received by the client
> 3] a fraction that may succeed or fail, but much more slowly due to retry
> behavior with its set of lovely constants and backoffs

Yes that's exactly it.

> If I've got that (at least vaguely) right, there seem to be situational
> tradeoffs as to whether that is 'better' or not. Sounds like good
> discussion material in a tuning doc :)

By definition, tuning has to be performed according to a specific
situation, otherwise it becomes the standard way of doing things.

> Within the scope of "TCP for HTTP" would you say something different? (and
> sure, I agree legacy TCP might not be the fun thing here.. but its the
> topic at hand.)

My goal as well is not to dictate what should be done, but to enumerate
known impacts of various choices on various actors so that we can always
refer to that in the future for various parts of protocol designs (eg:
we've done this already when documenting the fact that we must drain a
request body before closing or that there's a DoS risk for proxies
passing a close received from the client). In the end it should help us
design more robust and more infrastructure-friendly protocols. And
that's exactly what Daniel has begun with this nice document.

Thanks for your support ;-)
Willy