[Reposted to list] Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP
Kari Hurtta <hurtta-ietf@elmme-mailer.org> Sat, 05 March 2016 12:43 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 E75721B3058 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 5 Mar 2016 04:43:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 uGwswcllZKPe for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 5 Mar 2016 04:43:47 -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 668CD1B3054 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 5 Mar 2016 04:43:47 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1acBTz-0004fx-Mi for ietf-http-wg-dist@listhub.w3.org; Sat, 05 Mar 2016 12:38:55 +0000
Resent-Message-Id: <E1acBTz-0004fx-Mi@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 <ylafon@w3.org>) id 1acBTs-0004eZ-6k for ietf-http-wg@listhub.w3.org; Sat, 05 Mar 2016 12:38:48 +0000
Received: from raoul.w3.org ([128.30.52.128]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1acBTp-0007e6-Ef for ietf-http-wg@w3.org; Sat, 05 Mar 2016 12:38:47 +0000
Received: from platy.fdn.fr ([80.67.176.7] helo=[192.168.1.40]) by raoul.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <ylafon@w3.org>) id 1acBTo-00093L-BM for ietf-http-wg@w3.org; Sat, 05 Mar 2016 12:38:44 +0000
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_DD2BCF34-47AA-47EF-BA94-784FDC350190"
To: Willy Tarreau <w@1wt.eu>, HTTP WG <ietf-http-wg@w3.org>
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
In-Reply-To: <20160305072653.GA31072@1wt.eu>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Sat, 05 Mar 2016 08:32:24 +0000
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Joe Touch <touch@isi.edu>
Resent-Date: Sat, 05 Mar 2016 13:38:40 +0100
Message-Id: <201603050831.u258VCO2015766@shell.siilo.fmi.fi>
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
References: <20160305062609.E5D46209A@welho-filter1.welho.com> <20160305072653.GA31072@1wt.eu>
Resent-To: ietf-http-wg@w3.org
X-Mailer: Apple Mail (2.3112)
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, AWL=-2.256, BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: maggie.w3.org 1acBTp-0007e6-Ef 29078afe7be6154fe1b221f2c3988af3
X-Original-To: ietf-http-wg@w3.org
Subject: [Reposted to list] Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP
Archived-At: <http://www.w3.org/mid/201603050831.u258VCO2015766@shell.siilo.fmi.fi>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31191
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>
Willy Tarreau <w@1wt.eu>: (Sat Mar 5 09:26:53 2016) <...> >> So it is not that you have only two options. > > Absolutely, your points should also be noted in the doc, it's > too bad you didn't post to the list :-) > > Regards, > Willy OK. I repost that on list. Message should be included (some mail clients may show it as attachment). / Kari Hurtta ( not on list ) ================================================================ From: Kari Hurtta <hurtta-ietf@elmme-mailer.org> Subject: Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP Date: 5 March 2016 at 07:26:27 GMT+1 To: Willy Tarreau <w@1wt.eu> Cc: Joe Touch <touch@isi.edu>, Kari Hurtta <hurtta-ietf@elmme-mailer.org> ( not posted to list ) https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0330.html > What 17-year old wheels ? The only one I know about consists in patching > kernels to force shorter timewaits in order not to block outgoing > connections when the rate approaches 1000/s. Until we have 32 bits for > the source port, these are the only two options. At some point one must > not wonder why more and more the transport is migrating to userland :-/ Not actually, if talk is about reverse-proxy which sits front of web server pool. These two are not ONLY options. One possiblity: (which certain devices uses) * Do not "nat" connection from reverse proxy to webserver to proxy's local address. Instead use same source address on that connection than what was on http -request which reverse proxy reserved from client. In that may there equal number (or bigger number) of available (source address, source port, target address, target port) tupples than what was on client which sent request to reverse proxy (*). Web servers neeed to be default route (for connections received to that interface which sits on network between reverse proxy and webserver) to poit to reverse proxy. Reverse proxy need to able open TCP connection whit any source address (not just local address). Actually from this there is variations: # reuse connection from proxy to web server for several http request. On that situation web server does not see original source address address of client (but instead of some unrelated client -- this have some affects to access control) # "Nat" source address, but use pool of source addresses instead. If you use say 500 different source address, then you quite many available (source address, source port, target address, target port), so you can handle to 500 * 1000 connections per second from reverse proxy to webserver. You can guess what reverse proxy product uses these kind solutions. Perhaps there is also others. So it is not that you have only two options. / Kari Hurtta (*) You have begger number of source address, source port, target address, target port) availabe, when translate target address to web server's address and you have several web server's on pool. ( If you not translate target address, but instead route connections to correct web server. Then you have same number of tuples available. In that case web server actually need listen that address on loopback interface -- otherwise several web server haev same address on same network. )
- Call for Adoption: TCP Tuning for HTTP Mark Nottingham
- Re: Call for Adoption: TCP Tuning for HTTP Willy Tarreau
- Re: Call for Adoption: TCP Tuning for HTTP Tim Wicinski
- Re: Call for Adoption: TCP Tuning for HTTP Cory Benfield
- Re: Call for Adoption: TCP Tuning for HTTP Thomas Mangin
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Willy Tarreau
- Re: Call for Adoption: TCP Tuning for HTTP Scharf, Michael (Nokia - DE)
- Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tuning… Joe Touch
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Joe Touch
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Willy Tarreau
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Joe Touch
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Willy Tarreau
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Joe Touch
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Joe Touch
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Patrick McManus
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Willy Tarreau
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Willy Tarreau
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Joe Touch
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Willy Tarreau
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Joe Touch
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Patrick McManus
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Willy Tarreau
- Re: [tcpm] Call for Adoption: TCP Tuning for HTTP Mark Nottingham
- Re: [tcpm] Call for Adoption: TCP Tuning for HTTP Tim Wicinski
- Re: [tcpm] Call for Adoption: TCP Tuning for HTTP Willy Tarreau
- [Reposted to list] Re: Fwd: Re: [tcpm] FW: Call f… Kari Hurtta
- Re: [tcpm] Call for Adoption: TCP Tuning for HTTP Ben Niven-Jenkins
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Yoshifumi Nishida
- Re: [tcpm] Call for Adoption: TCP Tuning for HTTP Willy Tarreau
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Willy Tarreau
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Yoshifumi Nishida
- RE: Call for Adoption: TCP Tuning for HTTP Salvatore Loreto
- RE: Call for Adoption: TCP Tuning for HTTP Daniel Stenberg
- Re: Call for Adoption: TCP Tuning for HTTP Leif Hedstrom
- Re: Call for Adoption: TCP Tuning for HTTP Amos Jeffries
- Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tu… Willy Tarreau
- Re: Call for Adoption: TCP Tuning for HTTP Leif Hedstrom
- Re: Call for Adoption: TCP Tuning for HTTP Joe Touch
- Re: Call for Adoption: TCP Tuning for HTTP Matthew Kerwin
- RE: Call for Adoption: TCP Tuning for HTTP Daniel Stenberg
- RE: Call for Adoption: TCP Tuning for HTTP Daniel Stenberg