IETF Logo Mail Archive

Re: [tcpm] TCP Tuning for HTTP - update

Joe Touch <touch@isi.edu> Wed, 17 August 2016 04:21 UTC

Return-Path: <touch@isi.edu>
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 3914912D5AE for <tcpm@ietfa.amsl.com>; Tue, 16 Aug 2016 21:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.167
X-Spam-Level:
X-Spam-Status: No, score=-8.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247] 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 7_3vioqUXVah for <tcpm@ietfa.amsl.com>; Tue, 16 Aug 2016 21:21:41 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26EA312D126 for <tcpm@ietf.org>; Tue, 16 Aug 2016 21:21:41 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u7H4LAoU025750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Aug 2016 21:21:12 -0700 (PDT)
To: Mark Nottingham <mnot@mnot.net>, tcpm@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
References: <0CC24FC1-37E1-4125-9627-05726A9D9406@mnot.net>
From: Joe Touch <touch@isi.edu>
Message-ID: <7fa95741-ac58-3183-1b92-238bd4b4dae6@isi.edu>
Date: Tue, 16 Aug 2016 21:21:06 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <0CC24FC1-37E1-4125-9627-05726A9D9406@mnot.net>
Content-Type: multipart/mixed; boundary="------------B84BA9D3A06B2BC51706E71F"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/15ewBGnwlIZ_du3NdaoHQ2lwQjk>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Daniel Stenberg <daniel@haxx.se>
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: Wed, 17 Aug 2016 04:21:43 -0000

Hi, Mark, et al.,

I posted a review of this document to both to TCPM and HTTP WGs.

This update fails to address the issues I raised - notably that many of
the issues therein are known *and published*.

So first, can we discuss the issue of PLAGIARISM?

Not only of two of my works, but of many others that pointed out most of
the information summarized in this doc.

Second, the step of "adoption" needs to wait until there's something new
here that wasn't known 20 years ago and the issue of plagiarism is
addressed.

Joe

On 8/16/2016 7:02 PM, Mark Nottingham wrote:
> Hi TCPM,
>
> Just a quick note; Daniel and Tim have made an update to the TCP Tuning for HTTP draft:
>   https://tools.ietf.org/html/draft-stenberg-httpbis-tcp
>
> We've had a Call for Adoption open for this draft for a while, and will likely adopt it soon. However, we'd like to get feedback from this community first -- both about the latest version of the input document, and to see if there's interest in helping out.
>
> You can give feedback on the HTTP WG mailing list <https://lists.w3.org/Archives/Public/ietf-http-wg/>, or  by responding to this e-mail (Please leave the CC line; Patrick and I will try to summarise the feedback to the WG).
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
--- Begin Message --- 
Hi, all,

This doc was noted on the TCPM list.

See my observations below.

Joe


-------- Forwarded Message --------
Subject: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP
Date: Wed, 2 Mar 2016 12:25:07 -0800
From: Joe Touch <touch@isi.edu>
To: Scharf, Michael (Nokia - DE) <michael.scharf@nokia.com>,
tcpm@ietf.org Extensions <tcpm@ietf.org>
CC: touch@isi.edu



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
>
--- End Message ---
--- Begin Message --- 

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
>
--- End Message ---

v2.23.0 | Report a Bug | By Email