Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP
Joe Touch <touch@isi.edu> Wed, 02 March 2016 20:25 UTC
Return-Path: <touch@isi.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B56E1B2F84 for <tcpm@ietfa.amsl.com>; Wed, 2 Mar 2016 12:25:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] 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 u5-l_eBB92lr for <tcpm@ietfa.amsl.com>; Wed, 2 Mar 2016 12:25:32 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C2D1B2F83 for <tcpm@ietf.org>; Wed, 2 Mar 2016 12:25:32 -0800 (PST)
Received: from [128.9.184.68] ([128.9.184.68]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u22KPAAC016052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 2 Mar 2016 12:25:10 -0800 (PST)
To: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
References: <655C07320163294895BBADA28372AF5D486E00B7@FR712WXCHMBA15.zeu.alcatel-lucent.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <56D74C23.5010705@isi.edu>
Date: Wed, 02 Mar 2016 12:25:07 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <655C07320163294895BBADA28372AF5D486E00B7@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpm/k-Rj_NHRacgz2yECG57llAIfuhA>
Cc: touch@isi.edu
Subject: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 02 Mar 2016 20:25:34 -0000
On 3/2/2016 1:39 AM, Scharf, Michael (Nokia - DE) wrote: > I assume this could be of interest to the TCPM community. I have doubts: - it reads like a Linux manual page All Linux-specific references and commands would need to be moved to an appendix to be useful as an RFC. - this repeats (sometimes correctly, sometimes in error) existing advice J. Heidemann, K. Obraczka, J. Touch, “Modeling the Performance of HTTP Over Several Transport Protocols,” IEEE/ACM Transactions on Networking, V5, N5, Oct. 1997, pp.616-630. T. Faber, J. Touch, and W. Yue, “The TIME-WAIT state in TCP and Its Effect on Busy Servers,” in Proc. IEEE Infocom, 1999, pp. 1573-1583. - it has significant errors TIME-WAIT issues apply to servers, not clients. Nagle has been known to perform poorly for multibyte interactive traffic for a very long time, including not only web traffic but also multi-byte character or keyboard signals. Disabling slow-start after idle is safe only with pacing. Without pacing, the resulting traffic can generate a burst that was never experienced and result in both poor performance for the current connection and potential impact to competing traffic. (those are just a few) Overall, I think a man page might be useful, but this summary isn't useful for the IETF. Joe > -----Original Message----- > From: Scharf, Michael (Nokia - DE) > Sent: Wednesday, March 02, 2016 10:37 AM > To: 'Mark Nottingham'; HTTP WG > Cc: amankin@verisign.com; Daniel Stenberg > Subject: RE: Call for Adoption: TCP Tuning for HTTP > > The document refers to several TCPM RFCs with experimental status, e.g., in Section 3. That may have to be taken into account when heading towards BCP status. > > Michael > (TCPM co-chair) > > > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Wednesday, March 02, 2016 6:47 AM > To: HTTP WG > Cc: amankin@verisign.com; Daniel Stenberg > Subject: Call for Adoption: TCP Tuning for HTTP > > [ copying Alison as our Transport Tech Advisor ] > > Daniel has kindly started a document about how HTTP uses TCP, both for /1 and /2: > <https://tools.ietf.org/html/draft-stenberg-httpbis-tcp> > > We haven't explicitly discussed this at a meeting, but I have heard interest in this topic from a variety of folks. > > What do people think about adopting this with a target of Best Current Practice? > > Please comment on-list. > > Regards, > > -- > Mark Nottingham https://www.mnot.net/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >
- [tcpm] FW: Call for Adoption: TCP Tuning for HTTP Scharf, Michael (Nokia - DE)
- Re: [tcpm] FW: Call for Adoption: TCP Tuning for … gorry
- Re: [tcpm] FW: Call for Adoption: TCP Tuning for … Joe Touch
- Re: [tcpm] FW: Call for Adoption: TCP Tuning for … Scharf, Michael (Nokia - DE)