Re: [tcpm] TCP Tuning for HTTP - update

[Joe Touch <[e-mail]>]

Popping up to the key point...

On 8/17/2016 4:35 PM, Matthew Kerwin wrote:
> Hi folks, I'm stepping in here on just a couple of points. I'll snip
> the bits I can't or won't talk to.
...
> Where we come from, how we find information to solve our problems, the
> way we view the IETF and its RFCs are all different. If this argument
> is just that this stuff doesn't belong in an RFC, that's a cultural
> issue and not one I think we can resolve in this one technical working
> group.

IMO, RFCs deal with *protocols* and protocol deployment issues.

Here that would mean for HTTP in specific
    - turn Nagle off
    - watch out for ACK compression effects (turn it off in favor of ABC
if you can)
    - deal with slow-start restart (there are a variety of approaches here)

You also want to be generally efficient with TCP, which isn't related to
HTTP but still good advice for all apps:
    - be generally efficient and robust (use SACK, ECN, good window
scaling, etc.)
    - watch out for resource overloads (use SYN cookies/fast open,
time-wait buildup, etc.)

That advice is useful for all TCP for transactions, too.

Here's what it definitely does not mean:
    - setting socket buffer sizes (that's an OS-ism, and may be useful
for app designers to know, but isn''t directly part of TCP or HTTP)
    - running an efficient server for small connections (that's a pure
implementation performance issue, and depends on OS support for things
like threads, process/thread pools, etc.)
 
I.e., OS-specific issues in running servers are not in scope IMO.

Keep in mind who reads RFCs - mostly protocol people. Managers take
training courses to get certification, and that's where they learn their
operational issues.

Joe