Re: [tcpm] TCP Tuning for HTTP - update

Mark Nottingham <> Thu, 18 August 2016 00:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B77112D5AD for <>; Wed, 17 Aug 2016 17:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.168
X-Spam-Status: No, score=-8.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 90Z4X9LhqKht for <>; Wed, 17 Aug 2016 17:56:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A423F12B02C for <>; Wed, 17 Aug 2016 17:56:38 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1baBZI-0005lc-GP for; Thu, 18 Aug 2016 00:52:24 +0000
Resent-Date: Thu, 18 Aug 2016 00:52:24 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1baBZC-0005kg-NG for; Thu, 18 Aug 2016 00:52:18 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1baBZ5-0004eJ-Gq for; Thu, 18 Aug 2016 00:52:17 +0000
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 7CB5122E1FA; Wed, 17 Aug 2016 20:51:42 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Thu, 18 Aug 2016 10:51:39 +1000
Cc:, HTTP Working Group <>, Patrick McManus <>, Daniel Stenberg <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Joe Touch <touch@ISI.EDU>
X-Mailer: Apple Mail (2.3124)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.3
X-W3C-Hub-Spam-Report: AWL=1.351, 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: 1baBZ5-0004eJ-Gq 85106713df207a75d1defba0cddd29c6
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <>
X-Mailing-List: <> archive/latest/32300
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

The AD has spoken, and I think we're rapidly approaching the point of being off-topic here. I'll respond to your question below, and of course if you change your mind and do want to follow up with a helpful list of suggested references, you're most welcome.

> On 18 Aug 2016, at 1:08 AM, Joe Touch <touch@ISI.EDU> wrote:
>>>> If that's the case, I'd observe that the IETF isn't an academic publisher, and acknowledging all prior work in an area is neither practical, nor required, nor current practice.
>>> Plagiarism isn't an issue limited to academic environments. Publication
>>> of a document on the web is still publication.
>> Sure. It also isn't a legal issue in this form (unless you're asserting copyright?). Effectively, it's a cultural norm. Again, I will point out that in the culture of the IETF, we historically have not cited the complete provenance of every idea, both because it's impractical and because it doesn't benefit the reader. 
> Although that's true in the smallest cases, the IETF does have two
> concepts that support this norm: an author list and a set of references.
> Can you explain how it helps the reader to not cite two documents that
> are both squarely in the same area as this doc (interaction between HTTP
> and TCP and the impact of running many small connections closed at the
> client as for HTTP)?

Oh, it can be very helpful; I don't think anyone disputes that appropriate references are helpful. 

Whether or not specific documents -- such as yours -- should be referenced is a matter for editorial discretion and eventually WG consensus.  

I note that no one else has supported your claims, but others have said (e.g., [1]) that your work probably isn't appropriate for the intended audience (HTTP implementers and administrators).

Directing Daniel to add citations to mollify you at this point would be entirely inappropriate, because it would give an incentive to others who want their works cited without full review to make similar claims -- whether that be due to a genuine desire to help, a desire to increase their h-index, or to bolster an IPR claim against a technology.

Or, of course, Daniel could use his editorial discretion to decide to cite your work before the WG adopts it; however, I'd very much understand if he didn't want to do so at this point.



Mark Nottingham