Re: [tcpm] TCP Tuning for HTTP - update

Joe Touch <> Thu, 18 August 2016 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7671C12D7AF for <>; Wed, 17 Aug 2016 18:04:53 -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 F_EvaH7UQWYk for <>; Wed, 17 Aug 2016 18:04:46 -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 2614612D0A4 for <>; Wed, 17 Aug 2016 18:04:46 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1baBhJ-0004Pk-TY for; Thu, 18 Aug 2016 01:00:41 +0000
Resent-Date: Thu, 18 Aug 2016 01:00:41 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1baBhD-0004Ov-Hj for; Thu, 18 Aug 2016 01:00:35 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA256:128) (Exim 4.80) (envelope-from <>) id 1baBhA-0005Mi-40 for; Thu, 18 Aug 2016 01:00:33 +0000
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u7I0xX8w029196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Aug 2016 17:59:34 -0700 (PDT)
To: Mark Nottingham <>
References: <> <> <> <> <> <> <>
Cc:, HTTP Working Group <>, Patrick McManus <>, Daniel Stenberg <>
From: Joe Touch <>
Message-ID: <>
Date: Wed, 17 Aug 2016 17:59:30 -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: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.2
X-W3C-Hub-Spam-Report: AWL=1.274, BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1baBhA-0005Mi-40 648e4140af6fb06603ab7c97bf265d95
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <>
X-Mailing-List: <> archive/latest/32301
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


My point is simple: this work is useless if it fails to cite the
relevant prior work that explains the rationale behind its recommendations.

Mine isn't the only work not being cited here - there's all the work in
TCP tuning from PSC, many web workshops from the 90s, and numerous RFCs
and books. I've pointed out just a few.

I don't care to do the author's homework, but as AD I'm disappointed you
don't seem to care about that either.


On 8/17/2016 5:51 PM, Mark Nottingham wrote:
> 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.
> Regards,
> 1.
> --
> Mark Nottingham