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

Mark Nottingham <mnot@mnot.net> Fri, 04 March 2016 23:01 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B001ABB1A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 4 Mar 2016 15:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 0FzeKyaG584Y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 4 Mar 2016 15:01:38 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553C31A9308 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 4 Mar 2016 15:01:37 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1abyeM-0004cm-QU for ietf-http-wg-dist@listhub.w3.org; Fri, 04 Mar 2016 22:56:46 +0000
Resent-Date: Fri, 04 Mar 2016 22:56:46 +0000
Resent-Message-Id: <E1abyeM-0004cm-QU@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1abyeD-0004bz-98 for ietf-http-wg@listhub.w3.org; Fri, 04 Mar 2016 22:56:37 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1abye9-0004VY-5f for ietf-http-wg@w3.org; Fri, 04 Mar 2016 22:56:36 +0000
Received: from [192.168.1.109] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 08C3A22E271; Fri, 4 Mar 2016 17:56:04 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <56D9D235.9000106@isi.edu>
Date: Sat, 05 Mar 2016 09:56:01 +1100
Cc: Patrick McManus <mcmanus@ducksong.com>, Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA915C37-6831-44A6-86B0-E9A5E3DD909E@mnot.net>
References: <56D74C23.5010705@isi.edu> <56D76A7E.7090507@isi.edu> <20160302232125.GA18275@1wt.eu> <56D77892.2000308@isi.edu> <20160303065545.GA18412@1wt.eu> <56D87BAC.4060204@isi.edu> <20160303184418.GA18774@1wt.eu> <CAOdDvNokUDxmfy87VrQNLoQvQknP6L3h6fLbuFeVpOiDN4szAQ@mail.gmail.com> <56D9D235.9000106@isi.edu>
To: Joe Touch <touch@ISI.EDU>
X-Mailer: Apple Mail (2.3112)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.359, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1abye9-0004VY-5f cf28c34af6d487af2cb41342b99cdefe
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [tcpm] Call for Adoption: TCP Tuning for HTTP
Archived-At: <http://www.w3.org/mid/FA915C37-6831-44A6-86B0-E9A5E3DD909E@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31186
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Everyone,

A significant amount of IETF time and effort has been spent recently on trying to make sure that transport and application work is well-aligned; especially, that transport decisions are made with input from actual applications folks and vice-versa.

I've had encouraging discussions in the background with the transport ADs and others about coordinating to assure that this work -- if it gets taken on -- will help in those efforts. Right now we're figuring out exactly how that will occur, but suffice it to say that we won't be moving forward on this document until after B-A.

In the meantime, I'd encourage everyone to view this as an opportunity to learn more about how TCP is used by applications, and to learn more about how applications can get the most out of TCP. The discussion so far has been illuminating, please continue.

With regard to where the work is done -- that's certainly one of the things that we'll discuss, but I'll observe that while discussion about changing TCP should certainly take place in TCP-related fora, it's not reasonable to say that discussion about how applications  *use* TCP can only happen there.

With regard to the advice found on Google -- I think the point here is to provide an authoritative source to counter the misinformation out in the community. The document we're considering may not be in a suitable state to do that, but I'm confident we can get it there with appropriate participation.

Joe, you also said:

> The value would be in exploring the literature on the subject of designing large servers.


That is certainly *a* place we could find value. However, it is not the only place, and we're lucky enough to have a community of people on this list who develop and deploy some of the largest HTTP implementations (client, server and proxy), so I suggest it'd be best to consider them a source of value too.

Cheers,


> On 5 Mar 2016, at 5:21 AM, Joe Touch <touch@ISI.EDU> wrote:
> 
> Popping back up to the main point:
> 
> - there is very little in this doc that is specific to HTTP
> 
> 	there is a lot of good advice in the literature
> 	about how to implement big servers (incl. TCP-based),
> 	and there is no good reason to try to condense that into
> 	an RFC
> 
> - the advice in this doc is often at odds with existing TCP advise
> 
> 	Advice on changing/configuring TCP ought to happen on TCPM
> 	or TSVWG, not here.
> 
> IMO, the doc in its current form is no better than the kind of advice
> that can be found on Google.
> 
> Joe
> 

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