Re: [tcpm] TCP Tuning for HTTP - update

Mark Nottingham <mnot@mnot.net> Fri, 19 August 2016 03:49 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0145012D593 for <tcpm@ietfa.amsl.com>; Thu, 18 Aug 2016 20:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC4a6R62B3Of for <tcpm@ietfa.amsl.com>; Thu, 18 Aug 2016 20:49:33 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667A612B041 for <tcpm@ietf.org>; Thu, 18 Aug 2016 20:49:33 -0700 (PDT)
Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 98DD022E259; Thu, 18 Aug 2016 23:49:24 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <7a36e025-4882-4f8b-7a83-9fdcd990a971@isi.edu>
Date: Fri, 19 Aug 2016 13:49:21 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <BFE4FC25-CCCA-4390-AADD-BCDBFE798790@mnot.net>
References: <5CD67877-19E3-4E79-BBF2-3E270343A378@mnot.net> <2197232f-10d7-28cb-fcc9-05bd495e3c22@isi.edu> <20160817064545.GD16017@1wt.eu> <7f7b129c-f156-d067-bef8-4a2213f461ac@isi.edu> <20160817180802.GA16773@1wt.eu> <4ab7c5b0-3722-1346-f481-a8d76de70034@isi.edu> <20160817211317.GA16929@1wt.eu> <c928d1ca-fc89-d0b0-4e1a-8a0bd960d2bb@isi.edu> <CACweHNC1qFH5DMnZRE87bAE5sk_P+1z1Fzm-9YEu=E2DULkaYQ@mail.gmail.com> <27b58b64-48cd-39af-78b3-ef583c585fa6@isi.edu> <20160818053837.GC16773@1wt.eu> <7a36e025-4882-4f8b-7a83-9fdcd990a971@isi.edu>
To: Joe Touch <touch@ISI.EDU>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/O5MQI3ph4Hs8iMvfIVF2_gsyBQU>
Cc: tcpm@ietf.org, Matthew Kerwin <matthew@kerwin.net.au>, Daniel Stenberg <daniel@haxx.se>, Patrick McManus <pmcmanus@mozilla.com>, Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: [tcpm] TCP Tuning for HTTP - update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2016 03:49:36 -0000

> On 19 Aug 2016, at 1:07 AM, Joe Touch <touch@ISI.EDU> wrote:
> 
> I do think that this doc needs to figure out whom it is speaking to, what advice they actually need, etc.
> 
> If the result is a set of recommendations that involve the word "sysctl", I remain skeptical it is appropriate as an RFC


I think there's broad agreement on both of these points.

I'm wondering if it makes sense to aim it primarily at HTTP implementers rather than administrators, with the notion that it would inform:

- Their implementation decisions
- The configuration choices they offer to administrators / users
- Their documentation (e.g., advice to their administrators when the implementation can't change the appropriate parts of the OS)

Would that help? 

If so, it might make sense to organise it into sections for clients and servers (and intermediaries, if there's anything that isn't covered by the combination of the first two). Although IIRC Daniel was already talking about doing that.

Cheers,

--
Mark Nottingham   https://www.mnot.net/