Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP
Patrick McManus <mcmanus@ducksong.com> Fri, 04 March 2016 21:21 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 6ABF61A8F3B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 4 Mar 2016 13:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.28
X-Spam-Level:
X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 UVxwhtnAF1nF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 4 Mar 2016 13:21:48 -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 23DE31A8F3C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 4 Mar 2016 13:21:46 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1abx5j-00080q-LZ for ietf-http-wg-dist@listhub.w3.org; Fri, 04 Mar 2016 21:16:55 +0000
Resent-Date: Fri, 04 Mar 2016 21:16:55 +0000
Resent-Message-Id: <E1abx5j-00080q-LZ@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 <mcmanus@ducksong.com>) id 1abx5d-000800-Nb for ietf-http-wg@listhub.w3.org; Fri, 04 Mar 2016 21:16:49 +0000
Received: from www.ducksong.com ([192.155.95.102] helo=linode64.ducksong.com) by maggie.w3.org with esmtp (Exim 4.80) (envelope-from <mcmanus@ducksong.com>) id 1abx5b-0000gW-8Y for ietf-http-wg@w3.org; Fri, 04 Mar 2016 21:16:49 +0000
Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id 710EB3A01D for <ietf-http-wg@w3.org>; Fri, 4 Mar 2016 16:16:22 -0500 (EST)
Received: by mail-vk0-f52.google.com with SMTP id e6so66822522vkh.2 for <ietf-http-wg@w3.org>; Fri, 04 Mar 2016 13:16:22 -0800 (PST)
X-Gm-Message-State: AD7BkJJQCB7kXf38zGOJVAzunbEkV4UtbXPYnEwhSrS3HFkiUlFo9F7T0BTfRpCoIsFofVY6qZuGcZ46x8IpsA==
MIME-Version: 1.0
X-Received: by 10.31.135.79 with SMTP id j76mr7040824vkd.91.1457126182180; Fri, 04 Mar 2016 13:16:22 -0800 (PST)
Received: by 10.176.64.72 with HTTP; Fri, 4 Mar 2016 13:16:22 -0800 (PST)
In-Reply-To: <20160303220108.GB23875@1wt.eu>
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> <20160303220108.GB23875@1wt.eu>
Date: Fri, 04 Mar 2016 16:16:22 -0500
X-Gmail-Original-Message-ID: <CAOdDvNohs9TpLxMg-Vn-B=Ux2VumPL92hgqubARa7cgVinUmDg@mail.gmail.com>
Message-ID: <CAOdDvNohs9TpLxMg-Vn-B=Ux2VumPL92hgqubARa7cgVinUmDg@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Patrick McManus <mcmanus@ducksong.com>, Joe Touch <touch@isi.edu>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a114592e47b6102052d3fa0ee"
Received-SPF: pass client-ip=192.155.95.102; envelope-from=mcmanus@ducksong.com; helo=linode64.ducksong.com
X-W3C-Hub-Spam-Status: No, score=-5.6
X-W3C-Hub-Spam-Report: AWL=-0.705, BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1abx5b-0000gW-8Y e1de6825f10a41ac93e667f9c470526c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP
Archived-At: <http://www.w3.org/mid/CAOdDvNohs9TpLxMg-Vn-B=Ux2VumPL92hgqubARa7cgVinUmDg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31184
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>
To the extent this document can help promote efficient interop, rather than just application tuning (and I acknowledge that is a blurry line), I think it has promise as an IETF work and support adoption. I was skeptical of it being able to play that role, but I think Wily has raised an interesting point along those lines below. The document is clearly an -01 which needs more exploration but it was nice of Daniel to put something forward. (Daniel is afk for a bit - I'm sure we'll hear from him in the coming days.) On Thu, Mar 3, 2016 at 5:01 PM, Willy Tarreau <w@1wt.eu> wrote: > monitors). Many firewalls are tuned with aggressive FIN_WAIT/TIME_WAIT > timeouts which cause their session to expire before the other side dares > to retransmit. The server then remains for a long time in LAST_ACK state, > resending this last ACK packet for some time before giving up. > Wily, thanks for the giant wall of text :). I have tried to distill it to this, which I think is the essence of the discussion. I think the firewall issue is one worth documenting for interop purposes - it can't know the end state of receivers on either side so at least from a forwarding perspective it should be configured permissively in an environment that anticipates low TW. That seems like a valuable point to capture. > But by this time, our nice client has already used all other ports and > needs to reuse this port. Since its TIME_WAIT timeout was reduced to > something lower than the server's LAST_ACK, it believes the port is > free and reuses it. It sends a SYN which passes through the firewall, > this SYN reaches the server which disagrees and sends an RST back > (when the client picked a new SYN above the end of previous window) > or an ACK which will generally be blocked by the firewall, or if the > firewall accepts it, will be transmitted to the client which will then > send an RST, wait one second and send the SYN again. As you can imagine, > this dance is quite counter-productive for the performance since you > convert hundreds of microseconds to multiples of seconds to establish > certain connections. > This is interesting, and a bit different than the integrity issues an established frame could inject normally associated with TW (which https can protect against - at least in a deterministic fast fail sense). 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 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 :) 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.)
- 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